文章目录前言为什么布局一碰到长文案就容易露馅场景消息中心的异常通知卡片布局策略实操步骤先把卡片里谁不能退让想清楚完整示例可承受长文案的通知列表把关键代码一段段拆开容易踩坑的点优化建议异常文案要按信息优先级让位写在最后前言异常文案是检验布局韧性的最好材料。标题一长、按钮一多、屏幕一窄平时看起来很整齐的卡片就可能把操作区挤没。这篇单独聊长标题卡片这个场景。重点不是堆 API而是用弹性布局保证极端文案、按钮和状态标签不会互相挤压。为什么布局一碰到长文案就容易露馅因为正常文案太容易把页面骗过去了。四五个字的标题、短短一行说明、两个字的按钮看起来怎么排都顺。可一旦换成真实业务里的异常标题、设备编号、英文长串和多语言翻译很多原本“挺整齐”的布局马上就会露底按钮被挤扁标签换行卡片高度失控。所以这篇文章真正想解决的不是让页面在理想文案下好看而是让它在最麻烦的文案下也别崩。场景消息中心的异常通知卡片真实业务里的文案不会总是四个字。订单异常、设备离线、地址识别失败、活动审核驳回这些标题经常又长又具体。消息中心如果只按短文案设计最常见的问题就是标题把按钮挤没状态标签换行变形或者整张卡片高度突然失控。我做这类卡片时会先保护关键操作按钮必须可点状态必须可读主文案可以伸缩和截断。也就是说布局不是让所有内容都完整显示而是在小屏和长文案下保住信息优先级。UI 稳不稳要看最长文案、最小屏幕、最大字号下会不会崩。布局策略元素布局策略原因状态标签固定内容宽度不参与伸缩避免“异常”被压变形主标题layoutWeight(1)maxLines吸收剩余空间操作按钮固定宽高保证可点击区域辅助说明单独放下一行避免和按钮抢空间时间文案弱化显示信息重要性低于标题实操步骤先确定卡片里谁必须完整显示通常是状态和按钮。主标题放在可伸缩区域使用layoutWeight(1)。长文案设置maxLines和textOverflow不要撑破卡片。辅助说明放到下一行不要和操作按钮同排硬挤。用短文案、长文案、无空格长串、较大字号都测一遍。列表 key 使用业务 id避免异常通知刷新时错位。先把卡片里谁不能退让想清楚做异常通知卡片时先别急着调Row和Column。更重要的是先判断这一排里谁必须保住谁可以让位。大多数情况下操作按钮必须可点状态标签必须可读标题可以适当截断辅助说明可以放到下一行。你先把这个优先级排清楚再去看layoutWeight(1)、固定宽度和换行策略就会明白这些 API 不是随便拼出来的而是在帮你执行“谁保留、谁让位”这件事。对小白来说这一步能明显减少布局一乱就只会反复试数值的情况。完整示例可承受长文案的通知列表interfaceNoticeItem{id:numbertitle:stringdesc:stringaction:stringlevel:stringtime:string}EntryComponentstruct FlexibleTextPage{privatenotices:NoticeItem[][{id:1,title:订单已完成,desc:可查看订单详情和发票信息。,action:查看,level:normal,time:09:20},{id:2,title:由于收货地址包含无法识别的楼栋信息当前配送任务需要用户重新确认详细地址,desc:请在 24 小时内处理否则配送任务会自动暂停。,action:处理,level:warn,time:10:48},{id:3,title:DEVICE-ALPHA-2026-SUPER-LONG-NAME-NEEDS-CHECK,desc:设备名称来自外部系统可能没有自然断句。,action:检查,level:error,time:11:03}]privatelevelText(level:string):string{if(levelerror){return错误}if(levelwarn){return异常}return正常}privatelevelColor(level:string):string{if(levelerror){return#B42318}if(levelwarn){return#D92D20}return#0A7F3F}BuilderNoticeCard(item:NoticeItem){Column({space:8}){Row({space:10}){Text(this.levelText(item.level)).fontSize(12).fontColor(#FFFFFF).padding({left:6,right:6,top:3,bottom:3}).backgroundColor(this.levelColor(item.level)).borderRadius(4)Text(item.title).fontSize(15).fontColor(#222222).maxLines(2).textOverflow({overflow:TextOverflow.Ellipsis}).layoutWeight(1)Button(item.action).width(64).height(32).fontSize(12)}.width(100%)Row(){Text(item.desc).fontSize(13).fontColor(#666666).maxLines(2).textOverflow({overflow:TextOverflow.Ellipsis}).layoutWeight(1)Text(item.time).fontSize(12).fontColor(#999999).margin({left:8})}.width(100%)}.alignItems(HorizontalAlign.Start).padding(12).backgroundColor(#FFFFFF).borderRadius(8)}build(){Column({space:12}){Text(异常文案布局).fontSize(22).fontWeight(FontWeight.Bold)ForEach(this.notices,(item:NoticeItem){this.NoticeCard(item)},(item:NoticeItem)item.id.toString())}.padding(16).backgroundColor(#F5F7FA).height(100%)}}把关键代码一段段拆开标题使用layoutWeight(1)表示它占用标签和按钮之外的剩余空间。这样按钮不会被长标题挤出屏幕标题也不会和操作区重叠。maxLines(2)比单行截断更适合异常通知。异常文案通常需要多一点上下文两行能让用户看懂大概原因超过两行再省略避免卡片失控。辅助说明放在第二行和时间文案同排。主标题那一排已经有状态标签和按钮不应该再塞更多信息。信息层级清楚了弹性布局才有发挥空间。容易踩坑的点标题不设置最大行数长文案把卡片撑到半屏。按钮没有固定宽度被标题挤到只剩几个像素。状态标签参与伸缩文字被压缩或换行。只测试中文短句没有测试英文长串、设备编号、异常码。辅助说明和按钮放在同一行窄屏下互相抢空间。优化建议长文案不是单纯截断就完事。如果异常原因很重要可以点击卡片进入详情页展示完整内容列表里只保留摘要和动作。这样列表保持可扫读详情页承接完整解释。还要考虑字号放大和多语言。英文、数字、设备编号不一定有自然断点布局压力比中文更大。做国际化或系统字号适配时最好准备一组极端数据作为 UI 回归用例。如果团队里经常有人因为改文案把布局改崩我会把这些极端样例直接做成假数据常驻在开发环境里。这样每次改样式时都能顺手看到最坏情况而不是等测试阶段才发现按钮已经被长标题挤没。异常文案要按信息优先级让位弹性布局不是让所有内容都完整显示而是在空间不够时保住最重要的信息。异常通知里状态标签和操作按钮通常必须可见标题可以两行省略辅助说明可以弱化或交给详情页承接。示例让标题使用layoutWeight(1)吸收剩余空间按钮保持固定宽高状态标签不参与伸缩。这样长标题不会把按钮挤没用户仍然能完成处理动作。写在最后测试时不要只放正常中文短句。英文长串、设备编号、异常码、系统字号放大、多语言翻译都会给布局制造压力。能扛住这些异常文案卡片才算真正稳定。