企业官网建设流程全解析

1. 从命令式到声明式：AI组件库的架构选型思考

Android 原生 UI 开发在过去很长一段时间里，基本是View+XML的天下。写一个聊天界面，你得先定义RecyclerView，再写Adapter，再处理ViewHolder，再手动 diff 刷新，一套流程下来，业务逻辑还没写几行，样板代码已经堆了一屏。Jetpack Compose 出现之后，这套玩法被彻底掀翻了——UI 变成了状态的函数，状态变了，界面自动重组，开发者终于可以把精力放回业务本身。

但问题也随之而来：AI 类应用在移动端的交互形态，跟传统 App 差别太大了。流式输出、打字机效果、Markdown 实时渲染、代码块高亮、多轮对话气泡、输入框动态高度、消息列表自动滚动……这些东西如果每个项目都从零手搓，那 Compose 带来的效率红利基本就被抵消干净了。所以当我看到“Android Compose 版本的 AI 组件库”这个方向时，第一反应是：这个需求是真实存在的，而且相当迫切。

这篇文章想聊的，就是这样一个组件库从设计到落地的完整思路。我会把重点放在为什么这么设计、核心组件怎么实现、实际踩过哪些坑上，而不是简单罗列 API。如果你正在做 Android 端的 AI 对话类应用，或者想基于 Compose 搭一套可复用的聊天 UI 体系，那这篇内容应该能帮你省下不少试错时间。

1.1 为什么是 Compose，而不是继续用 View 体系

先说结论：AI 交互场景天然适合声明式 UI。原因有三点。

第一，流式数据的重组成本。AI 回复是一个 token 一个 token 吐出来的，界面需要高频局部刷新。传统 View 体系下，你要么用DiffUtil做增量更新，要么直接notifyItemChanged全量刷新，前者写起来繁琐，后者性能堪忧。Compose 的mutableStateOf配合derivedStateOf，天然支持细粒度重组，只有依赖变化的那部分 UI 会重新绘制，这个优势在流式场景下被放大了好几倍。

第二，动态布局的灵活性。AI 回复的内容长度不可预测，可能是一行字，也可能是几百行的代码块。Compose 的Column、Row、FlowRow组合起来，配合IntrinsicSize和SubcomposeLayout，处理这种不确定高度的内容比LinearLayout的weight机制舒服太多。

第三，状态管理的统一性。AI 应用的状态很复杂：加载中、流式输出中、已完成、出错、被中断……这些状态如果散落在ViewModel、Adapter、Fragment里，维护起来就是灾难。Compose 的State提升机制，让状态可以集中管理，UI 只负责消费，逻辑清晰得多。

当然，Compose 也不是银弹。它的学习曲线、编译速度、以及跟现有 View 体系的混用成本，都是真实存在的。但如果你的项目是全新的 AI 应用，或者 AI 模块是独立页面，那 Compose 几乎是当前最优解。

1.2 组件库的边界：该封装什么，不该封装什么

做组件库最容易犯的错误，就是什么都想封。封得太浅，用户觉得鸡肋；封得太深，用户觉得被绑架。我的经验是，AI 组件库的边界应该划在交互模式这一层，而不是业务逻辑这一层。

具体来说，应该封装的：

• 消息气泡的布局与样式（用户消息、AI 消息、系统消息）
• 流式文本的渲染与打字机效果
• Markdown 与代码块的解析渲染
• 输入框的自动增高、发送按钮状态联动
• 消息列表的自动滚动与“回到底部”按钮
• 加载态、错误态、重试态的统一样式

不应该封装的：

• 具体的网络请求逻辑（用 OkHttp 还是 Ktor，是 SSE 还是 WebSocket，交给用户）
• 数据模型的具体字段（Message类里该有什么，让用户自己定）
• 状态管理的具体方案（ViewModel 还是 Presenter，不强制）
• 主题色、字体、圆角这些视觉细节（提供默认值，但必须可覆盖）

这个边界划清楚之后，组件库的 API 设计就会自然很多。用户拿到手，只需要把数据喂进来，把回调接出去，中间那层交互细节全部由组件库兜底。

2. 核心组件拆解：从消息气泡到流式渲染

这一部分我会逐个拆解组件库里的核心模块，每个模块都会讲清楚设计意图、关键实现、以及实际使用中需要注意的细节。代码示例我会用 Kotlin + Compose 写，尽量保持可运行性，但为了篇幅考虑，会省略一些跟主题无关的 import 和辅助函数。

2.1 消息数据模型的设计取舍

组件库的第一块基石是数据模型。这里有个关键决策：组件库要不要定义自己的 Message 类？

我的选择是：定义一个最小化的接口，而不是具体的 data class。

interface ChatMessage { val id: String val role: MessageRole val content: String val timestamp: Long val status: MessageStatus } enum class MessageRole { USER, ASSISTANT, SYSTEM } enum class MessageStatus { SENDING, STREAMING, COMPLETED, ERROR }

为什么用接口而不是 data class？因为不同项目的消息模型差异太大了。有的项目需要tokenCount，有的需要attachments，有的需要parentMessageId。如果组件库强行定义一个包含所有字段的 data class，用户就得做一层无意义的映射。用接口的话，用户自己的Message类只需要实现这个接口，或者写一个扩展函数做适配，灵活得多。

status字段是重点。很多新手做 AI 聊天界面，只区分“发送中”和“已完成”，结果流式输出的时候没法区分“正在吐字”和“已经吐完”，导致光标闪烁逻辑、重试按钮的显示时机都很难处理。把STREAMING单独拎出来，后面做打字机效果和中断逻辑会轻松很多。

注意：id字段建议用 UUID 或者时间戳+随机数，不要用列表索引。流式更新时列表内容会变，用索引做 key 会导致 Compose 重组时状态错乱，这个坑我踩过不止一次。

2.2 消息气泡：不只是画个圆角矩形

消息气泡看起来简单，实际上要考虑的东西不少。先看基础实现：

@Composable fun MessageBubble( message: ChatMessage, modifier: Modifier = Modifier ) { val isUser = message.role == MessageRole.USER val bubbleColor = if (isUser) { MaterialTheme.colorScheme.primaryContainer } else { MaterialTheme.colorScheme.surfaceVariant } val alignment = if (isUser) Alignment.End else Alignment.Start val shape = if (isUser) { RoundedCornerShape(16.dp, 16.dp, 4.dp, 16.dp) } else { RoundedCornerShape(16.dp, 16.dp, 16.dp, 4.dp) } Box(modifier = modifier.fillMaxWidth(), contentAlignment = alignment) { Surface( color = bubbleColor, shape = shape, tonalElevation = 1.dp ) { Column(modifier = Modifier.padding(12.dp)) { MessageContent(message) if (message.status == MessageStatus.STREAMING) { StreamingCursor() } } } } }

几个细节值得展开说。

圆角的不对称处理。用户消息右下角小圆角，AI 消息左下角小圆角，这是聊天界面的通用视觉语言，能让人一眼分辨消息方向。别小看这 4dp 的差异，它比颜色区分更直观。

tonalElevation而不是shadow。Compose 的Surface用tonalElevation做层次感，比传统的elevation阴影更符合 Material Design 3 的规范，而且在深色模式下表现更自然。

流式光标的放置。光标要放在Column内部、内容之后，而不是气泡外部。这样光标会跟着文本自然流动，不会出现“文本换行了但光标还在上一行末尾”的尴尬情况。

最大宽度限制。实际使用中，消息气泡不能占满整个屏幕宽度，否则阅读体验很差。建议设置widthIn(max = 280.dp)或者用fillMaxWidth(0.85f)。这个值需要根据屏幕尺寸动态调整，平板和手机的合理值不一样。

2.3 流式文本渲染：打字机效果的三种实现路径

流式渲染是 AI 组件库的灵魂。实现方式大致有三种，各有优劣。

方案一：直接消费流式数据。网络层每收到一个 chunk，就更新content状态，Compose 自动重组。这是最自然的做法，但问题是如果 chunk 到达速度不均匀（网络抖动），界面会出现“一顿一顿”的卡顿感。

方案二：缓冲区 + 定时器。维护一个目标文本和一个显示文本，定时器每隔 16ms（一帧）从目标文本里取一部分追加到显示文本。这样无论网络多快多慢，显示速度都是均匀的。缺点是实现复杂，需要处理中断、暂停、加速等逻辑。

方案三：AnimatedContent或animateStringAsState。用 Compose 的动画 API 做插值，代码最简洁，但可控性最差，不适合需要精确控制光标位置和滚动行为的场景。

我最终选的是方案二，核心逻辑大概是这样：

@Composable fun StreamingText( targetText: String, isStreaming: Boolean, modifier: Modifier = Modifier ) { var displayText by remember { mutableStateOf("") } var lastUpdateTime by remember { mutableLongStateOf(0L) } LaunchedEffect(targetText, isStreaming) { if (!isStreaming) { displayText = targetText return@LaunchedEffect } while (displayText.length < targetText.length) { withFrameNanos { now -> if (now - lastUpdateTime >= 16_000_000L) { val remaining = targetText.length - displayText.length val step = when { remaining > 50 -> 3 remaining > 10 -> 2 else -> 1 } displayText = targetText.substring(0, displayText.length + step) lastUpdateTime = now } } } } Text(text = displayText, modifier = modifier) }

这里有个动态步长的设计：剩余字符多的时候一次多吐几个，剩余少的时候一次吐一个。这样既保证了长文本的显示速度，又保证了结尾处的细腻感。实测下来，这个策略比固定步长的体验好很多。

提示：withFrameNanos是 Compose 提供的帧同步 API，比delay(16)更精确，因为它跟屏幕刷新率对齐。在高刷屏上，它会自动适配 120Hz，不会出现固定 16ms 导致的抖动。

2.4 Markdown 与代码块渲染：别自己造轮子

AI 回复里出现 Markdown 是常态，尤其是代码块。自己写解析器？不现实。我的建议是：解析用成熟库，渲染用 Compose 重写。

解析层可以用commonmark-java或者markdown这类库，把 Markdown 文本解析成 AST（抽象语法树）。渲染层则用 Compose 的AnnotatedString和Text组合来实现。

@Composable fun MarkdownText( markdown: String, modifier: Modifier = Modifier ) { val blocks = remember(markdown) { parseMarkdown(markdown) } Column(modifier = modifier) { blocks.forEach { block -> when (block) { is MarkdownBlock.Paragraph -> { Text( text = buildAnnotatedString(block), style = MaterialTheme.typography.bodyMedium ) } is MarkdownBlock.CodeBlock -> { CodeBlockView( code = block.code, language = block.language ) } is MarkdownBlock.ListBlock -> { ListBlockView(block) } } } } }

代码块渲染有几个关键点：

• 横向滚动：代码行可能很长，必须支持横向滚动，否则会强制换行，可读性极差。
• 语法高亮：可以用Highlights或者自己写简单的关键字匹配。如果性能要求高，建议在后台线程做高亮，把结果缓存起来。
• 复制按钮：代码块右上角放一个复制按钮，这是刚需。复制的时候记得去掉行号和高亮标记，只复制纯代码。
• 语言标签：显示代码语言，方便用户判断内容类型。

注意：Markdown 解析和语法高亮都是 CPU 密集型操作，千万不要在主线程做。用remember缓存解析结果，用LaunchedEffect+Dispatchers.Default做异步解析，否则流式输出的时候界面会卡成幻灯片。

2.5 输入框：自动增高与发送状态联动

输入框的设计目标很明确：用户打字的时候，输入框高度跟着内容增长，但不超过一个上限；发送按钮根据输入内容是否为空自动启用或禁用。

@Composable fun ChatInputBar( onSend: (String) -> Unit, modifier: Modifier = Modifier ) { var inputText by remember { mutableStateOf("") } val canSend = inputText.isNotBlank() Row( modifier = modifier .fillMaxWidth() .padding(8.dp), verticalAlignment = Alignment.Bottom ) { BasicTextField( value = inputText, onValueChange = { inputText = it }, modifier = Modifier .weight(1f) .heightIn(min = 40.dp, max = 120.dp) .background( MaterialTheme.colorScheme.surfaceVariant, RoundedCornerShape(20.dp) ) .padding(horizontal = 16.dp, vertical = 10.dp), maxLines = 5 ) Spacer(modifier = Modifier.width(8.dp)) IconButton( onClick = { if (canSend) { onSend(inputText) inputText = "" } }, enabled = canSend ) { Icon(Icons.Default.Send, contentDescription = "发送") } } }

heightIn(min = 40.dp, max = 120.dp)配合maxLines = 5，实现了自动增高但不超过 5 行的效果。超过 5 行之后，输入框内部滚动。

发送按钮的enabled状态跟canSend绑定，视觉上可以用alpha做过渡，让禁用状态看起来更自然。

提示：BasicTextField比TextField更灵活，但需要自己处理 placeholder、光标颜色、背景等。如果不想折腾，用TextField配合colors参数也能达到类似效果，只是定制性差一些。

3. 消息列表与滚动行为：最容易被低估的模块

消息列表看起来就是LazyColumn包一下，但实际做起来，滚动行为的处理是最容易出 bug 的地方。这一部分我单独拎出来讲，因为它在 AI 聊天场景里的重要性远超普通列表。

3.1 自动滚动到底部的正确姿势

AI 回复的时候，列表需要自动滚动到底部，让用户看到最新内容。但这里有个矛盾：如果用户手动往上滑看历史消息，自动滚动就会把用户拽回底部，体验极差。

正确的逻辑应该是：

1. 默认情况下，新消息到达时自动滚动到底部。
2. 如果用户手动向上滚动，进入“自由浏览”模式，停止自动滚动。
3. 显示一个“回到底部”的悬浮按钮，用户点击后恢复自动滚动。
4. 用户手动滚回底部时，自动退出“自由浏览”模式。

@Composable fun MessageList( messages: List<ChatMessage>, modifier: Modifier = Modifier ) { val listState = rememberLazyListState() val isAtBottom by remember { derivedStateOf { val lastVisible = listState.layoutInfo.visibleItemsInfo.lastOrNull() lastVisible == null || lastVisible.index >= messages.lastIndex } } var autoScroll by remember { mutableStateOf(true) } LaunchedEffect(messages.size, messages.lastOrNull()?.content) { if (autoScroll && messages.isNotEmpty()) { listState.animateScrollToItem(messages.lastIndex) } } LaunchedEffect(isAtBottom) { if (isAtBottom) autoScroll = true } Box(modifier = modifier) { LazyColumn( state = listState, modifier = Modifier.fillMaxSize(), verticalArrangement = Arrangement.spacedBy(8.dp) ) { items(messages, key = { it.id }) { message -> MessageBubble(message = message) } } if (!isAtBottom) { FloatingActionButton( onClick = { autoScroll = true }, modifier = Modifier .align(Alignment.BottomEnd) .padding(16.dp) ) { Icon(Icons.Default.ArrowDownward, contentDescription = "回到底部") } } } }

这里的关键是derivedStateOf的使用。isAtBottom是根据listState计算出来的派生状态，它只会在实际值变化时触发重组，而不是每次滚动都触发。这个优化在长列表里非常明显。

LaunchedEffect的 key 里我加了messages.lastOrNull()?.content，这是为了处理流式输出的情况。流式输出时，消息数量不变，但最后一条消息的内容在变，所以需要用内容作为 key 来触发滚动。

注意：animateScrollToItem在流式输出高频调用时，可能会出现滚动动画排队、界面抖动的问题。如果遇到这种情况，可以改成scrollToItem（无动画），或者加一个节流逻辑，比如每 100ms 最多滚动一次。

3.2 键盘弹出时的布局适配

聊天界面另一个经典问题是：键盘弹出时，输入框要跟着上移，消息列表要相应缩短，而不是被键盘遮住。

在Activity的windowSoftInputMode设置为adjustResize的前提下，Compose 里可以用WindowInsets.ime来处理：

Column( modifier = Modifier .fillMaxSize() .imePadding() ) { MessageList( messages = messages, modifier = Modifier.weight(1f) ) ChatInputBar(onSend = { /* ... */ }) }

imePadding()会自动把 IME（输入法）的高度作为 padding 加到底部，输入框就会自然上移。这个 API 在 Compose 1.2 之后已经比较稳定了，但不同厂商的 ROM 表现可能有差异，建议在真机上多测几款。

提示：如果imePadding()在你的项目里表现异常，可以检查一下Activity是否设置了WindowCompat.setDecorFitsSystemWindows(window, false)。这个设置跟imePadding()是配套使用的，缺一不可。

3.3 长列表的性能优化

AI 聊天记录可能很长，几百条消息是常态。LazyColumn本身已经做了懒加载，但还有几个优化点：

• key 的稳定性：items的 key 必须用消息 id，不能用索引。用索引的话，插入新消息会导致所有 item 的状态错乱。
• contentType：如果消息类型多样（文本、图片、代码块），给items加contentType参数，Compose 会为不同类型复用不同的组合，提升复用效率。
• 避免在 item 内部做重计算：Markdown 解析、语法高亮这些操作，要么用remember缓存，要么放到 ViewModel 里预处理。
• 限制最大消息数：如果消息超过 500 条，考虑做分页加载或者截断，不要一次性全部塞进列表。

4. 常见问题与排查技巧实录

这一部分是我在实际开发和社区反馈里整理出来的高频问题。每个问题都附上排查思路和解决方案，希望能帮你少走弯路。

4.1 流式输出时界面卡顿

现象：AI 回复的时候，界面明显掉帧，滚动不流畅。

排查思路：

1. 先看是不是在主线程做了重计算。Markdown 解析、语法高亮、正则匹配，这些都是嫌疑对象。
2. 再看重组范围是不是过大。如果整个列表都在重组，而不是只有最后一条消息在重组，那性能肯定好不了。
3. 最后看状态更新频率。如果每个 token 都触发一次状态更新，而 token 到达速度又很快，那重组次数会爆炸。

解决方案：

• 把 Markdown 解析放到Dispatchers.Default，用produceState或者LaunchedEffect异步处理。
• 用derivedStateOf缩小重组范围，确保只有依赖变化的部分才重组。
• 对状态更新做节流，比如每 50ms 合并一次更新，而不是每个 token 都更新。

4.2 消息气泡宽度异常

现象：短消息的气泡也占满整行，或者长消息的气泡超出了屏幕边界。

排查思路：Compose 的Box默认是fillMaxWidth的，如果不加限制，子元素会被拉伸。

解决方案：

Box( modifier = Modifier.fillMaxWidth(), contentAlignment = if (isUser) Alignment.CenterEnd else Alignment.CenterStart ) { Surface( modifier = Modifier.widthIn(max = 280.dp), // ... ) { /* ... */ } }

关键是widthIn(max = ...)和contentAlignment的配合。widthIn限制最大宽度，contentAlignment控制气泡在行内的对齐方式。

4.3 键盘弹出后输入框被遮挡

现象：点击输入框，键盘弹出，但输入框被键盘盖住了。

排查思路：

1. 检查AndroidManifest.xml里对应 Activity 的windowSoftInputMode是不是adjustResize。
2. 检查是否调用了WindowCompat.setDecorFitsSystemWindows(window, false)。
3. 检查布局里是否用了imePadding()。

解决方案：这三个条件必须同时满足。缺任何一个，imePadding()都不会生效。

4.4 常见问题速查表

提示：这个表格建议收藏，遇到问题先对照排查，能省下大量调试时间。

4.5 几个容易被忽略的细节

时间戳的显示。聊天界面通常需要显示消息时间，但不需要每条都显示。常见的做法是：相邻消息间隔超过 5 分钟才显示时间戳。这个逻辑要在数据预处理阶段做好，不要放在 UI 层。

错误消息的重试。AI 请求失败是常态，错误消息旁边要有一个重试按钮。重试的时候，要把这条消息的状态改回SENDING，并重新发起请求。注意不要重复插入消息，而是更新原消息的状态。

长按复制。用户经常需要复制 AI 的回复。用combinedClickable实现长按弹菜单，菜单里放“复制”选项。复制的内容应该是纯文本，去掉 Markdown 标记。

空状态处理。新会话开始时，消息列表是空的。这时候应该显示一个引导页，而不是一片空白。引导页可以放一些示例问题，点击后自动填入输入框。

5. 组件库的扩展性与主题定制

一个组件库能不能被长期使用，很大程度上取决于它的扩展性。如果用户想改个颜色、换个字体、加个自定义消息类型，都要改源码，那这个库的生命周期不会太长。

5.1 主题系统的设计

我的做法是提供一个ChatTheme组合局部（CompositionLocal），把所有可定制的视觉参数集中管理：

data class ChatThemeData( val userBubbleColor: Color, val assistantBubbleColor: Color, val userBubbleShape: Shape, val assistantBubbleShape: Shape, val bubbleMaxWidth: Dp, val messageSpacing: Dp, val inputBarHeight: Dp ) val LocalChatTheme = compositionLocalOf { ChatThemeData(...) } @Composable fun ChatTheme( data: ChatThemeData = ChatThemeData.default(), content: @Composable () -> Unit ) { CompositionLocalProvider(LocalChatTheme provides data) { content() } }

用户只需要在根节点包一层ChatTheme，传入自定义的ChatThemeData，整个组件库的视觉风格就变了。不需要改任何组件内部代码。

5.2 自定义消息类型的扩展

组件库内置了文本消息、代码块消息，但用户可能还需要图片消息、文件消息、卡片消息。扩展方式应该是开放的：

@Composable fun MessageBubble( message: ChatMessage, customContent: (@Composable (ChatMessage) -> Unit)? = null ) { // ... if (customContent != null && message.role == MessageRole.CUSTOM) { customContent(message) } else { MessageContent(message) } }

通过传入customContent插槽，用户可以渲染任意类型的消息内容，而不需要修改组件库源码。

5.3 状态管理的解耦

组件库不应该强制用户使用某种状态管理方案。我的设计是：组件库只接收数据和回调，不持有状态。

@Composable fun ChatScreen( messages: List<ChatMessage>, inputText: String, onInputChange: (String) -> Unit, onSend: () -> Unit, onRetry: (String) -> Unit ) { // ... }

这样用户可以用ViewModel、Presenter、甚至Redux来管理状态，组件库完全不关心。这种“无状态”的设计，让组件库的适用范围大大扩展。

注意：无状态设计意味着组件库内部不能有remember的业务状态，只能有 UI 状态（比如滚动位置、动画进度）。这个边界要守住，否则组件库会变得越来越重。

6. 从组件库到产品：落地时的经验总结

组件库写完之后，真正把它用到产品里，还会遇到一些组件库层面解决不了的问题。这部分我分享几个实际落地时的经验。

6.1 网络层与 UI 层的契约

流式输出的网络层，通常用 SSE（Server-Sent Events）或者 WebSocket。不管用哪种，UI 层需要的都是一个Flow<String>。网络层应该把协议细节封装掉，只暴露一个流式的文本流。

interface ChatRepository { fun sendMessage(content: String): Flow<String> }

UI 层订阅这个 Flow，每收到一个 chunk，就更新对应消息的content。这个契约要提前定好，不然后面改起来很痛苦。

6.2 中断与取消的处理

用户可能在 AI 回复到一半的时候，点击“停止生成”。这时候需要：

1. 取消网络请求的订阅。
2. 把消息状态从STREAMING改成COMPLETED。
3. 保留已经生成的内容，不要清空。

取消订阅用Job.cancel()或者Flow的takeWhile都可以。关键是状态要同步更新，否则光标会一直闪。

6.3 多轮对话的上下文管理

AI 对话通常需要携带历史消息作为上下文。但历史消息不能无限增长，否则 token 消耗会爆炸。常见的策略是：

• 保留最近 N 轮对话（比如 10 轮）。
• 或者按 token 数量截断，保留最近的 M 个 token。
• 系统提示词（System Prompt）始终保留。

这个逻辑应该在 ViewModel 或者 Repository 层做，不要放在 UI 层。UI 层只负责展示完整的消息列表，发送请求时由上层决定带哪些上下文。

6.4 性能监控与优化

上线之后，建议加一些性能埋点：

• 首字延迟（从发送到收到第一个 token 的时间）。
• 流式输出的平均帧率。
• 消息列表的滚动帧率。
• 内存占用（长会话下的内存增长曲线）。

这些数据能帮你发现很多在开发阶段注意不到的问题。比如首字延迟过高，可能是网络层的问题；滚动帧率低，可能是列表 item 太重。

我个人在实际操作中的体会是，AI 组件库的价值不在于代码有多复杂，而在于它把那些琐碎但容易出错的交互细节都处理好了。流式渲染的节流、滚动行为的边界条件、键盘适配的兼容性、Markdown 渲染的性能……这些东西单独看都不难，但全部凑在一起，就是一个相当可观的工程量。有一个经过验证的组件库兜底，团队可以把精力集中在业务逻辑和产品体验上，而不是反复造轮子。

最后再分享一个小技巧：组件库的 API 设计，尽量用“插槽”而不是“配置项”。配置项是封闭的，用户只能在你预设的范围内定制；插槽是开放的，用户可以塞任何东西进去。比如消息气泡的内容区域，与其提供textStyle、maxLines、overflow一堆参数，不如直接暴露一个content: @Composable () -> Unit插槽，让用户自己决定怎么渲染。这样组件库的维护成本会低很多，用户的自由度也更大。