文章目錄前言為什么布局一碰到長文案就容易露餡場景消息中心的異常通知卡片布局策略實操步驟先把卡片里誰不能退讓想清楚完整示例可承受長文案的通知列表把關(guān)鍵代碼一段段拆開容易踩坑的點優(yōu)化建議異常文案要按信息優(yōu)先級讓位寫在最后前言異常文案是檢驗布局韌性的最好材料。標(biāo)題一長、按鈕一多、屏幕一窄平時看起來很整齊的卡片就可能把操作區(qū)擠沒。這篇單獨聊長標(biāo)題卡片這個場景。重點不是堆 API而是用彈性布局保證極端文案、按鈕和狀態(tài)標(biāo)簽不會互相擠壓。為什么布局一碰到長文案就容易露餡因為正常文案太容易把頁面騙過去了。四五個字的標(biāo)題、短短一行說明、兩個字的按鈕看起來怎么排都順?？梢坏Q成真實業(yè)務(wù)里的異常標(biāo)題、設(shè)備編號、英文長串和多語言翻譯很多原本“挺整齊”的布局馬上就會露底按鈕被擠扁標(biāo)簽換行卡片高度失控。所以這篇文章真正想解決的不是讓頁面在理想文案下好看而是讓它在最麻煩的文案下也別崩。場景消息中心的異常通知卡片真實業(yè)務(wù)里的文案不會總是四個字。訂單異常、設(shè)備離線、地址識別失敗、活動審核駁回這些標(biāo)題經(jīng)常又長又具體。消息中心如果只按短文案設(shè)計最常見的問題就是標(biāo)題把按鈕擠沒狀態(tài)標(biāo)簽換行變形或者整張卡片高度突然失控。我做這類卡片時會先保護關(guān)鍵操作按鈕必須可點狀態(tài)必須可讀主文案可以伸縮和截斷。也就是說布局不是讓所有內(nèi)容都完整顯示而是在小屏和長文案下保住信息優(yōu)先級。UI 穩(wěn)不穩(wěn)要看最長文案、最小屏幕、最大字號下會不會崩。布局策略元素布局策略原因狀態(tài)標(biāo)簽固定內(nèi)容寬度不參與伸縮避免“異?！北粔鹤冃沃鳂?biāo)題layoutWeight(1)maxLines吸收剩余空間操作按鈕固定寬高保證可點擊區(qū)域輔助說明單獨放下一行避免和按鈕搶空間時間文案弱化顯示信息重要性低于標(biāo)題實操步驟先確定卡片里誰必須完整顯示通常是狀態(tài)和按鈕。主標(biāo)題放在可伸縮區(qū)域使用layoutWeight(1)。長文案設(shè)置maxLines和textOverflow不要撐破卡片。輔助說明放到下一行不要和操作按鈕同排硬擠。用短文案、長文案、無空格長串、較大字號都測一遍。列表 key 使用業(yè)務(wù) id避免異常通知刷新時錯位。先把卡片里誰不能退讓想清楚做異常通知卡片時先別急著調(diào)Row和Column。更重要的是先判斷這一排里誰必須保住誰可以讓位。大多數(shù)情況下操作按鈕必須可點狀態(tài)標(biāo)簽必須可讀標(biāo)題可以適當(dāng)截斷輔助說明可以放到下一行。你先把這個優(yōu)先級排清楚再去看layoutWeight(1)、固定寬度和換行策略就會明白這些 API 不是隨便拼出來的而是在幫你執(zhí)行“誰保留、誰讓位”這件事。對小白來說這一步能明顯減少布局一亂就只會反復(fù)試數(shù)值的情況。完整示例可承受長文案的通知列表interfaceNoticeItem{id:numbertitle:stringdesc:stringaction:stringlevel:stringtime:string}EntryComponentstruct FlexibleTextPage{privatenotices:NoticeItem[][{id:1,title:訂單已完成,desc:可查看訂單詳情和發(fā)票信息。,action:查看,level:normal,time:09:20},{id:2,title:由于收貨地址包含無法識別的樓棟信息當(dāng)前配送任務(wù)需要用戶重新確認詳細地址,desc:請在 24 小時內(nèi)處理否則配送任務(wù)會自動暫停。,action:處理,level:warn,time:10:48},{id:3,title:DEVICE-ALPHA-2026-SUPER-LONG-NAME-NEEDS-CHECK,desc:設(shè)備名稱來自外部系統(tǒng)可能沒有自然斷句。,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%)}}把關(guān)鍵代碼一段段拆開標(biāo)題使用layoutWeight(1)表示它占用標(biāo)簽和按鈕之外的剩余空間。這樣按鈕不會被長標(biāo)題擠出屏幕標(biāo)題也不會和操作區(qū)重疊。maxLines(2)比單行截斷更適合異常通知。異常文案通常需要多一點上下文兩行能讓用戶看懂大概原因超過兩行再省略避免卡片失控。輔助說明放在第二行和時間文案同排。主標(biāo)題那一排已經(jīng)有狀態(tài)標(biāo)簽和按鈕不應(yīng)該再塞更多信息。信息層級清楚了彈性布局才有發(fā)揮空間。容易踩坑的點標(biāo)題不設(shè)置最大行數(shù)長文案把卡片撐到半屏。按鈕沒有固定寬度被標(biāo)題擠到只剩幾個像素。狀態(tài)標(biāo)簽參與伸縮文字被壓縮或換行。只測試中文短句沒有測試英文長串、設(shè)備編號、異常碼。輔助說明和按鈕放在同一行窄屏下互相搶空間。優(yōu)化建議長文案不是單純截斷就完事。如果異常原因很重要可以點擊卡片進入詳情頁展示完整內(nèi)容列表里只保留摘要和動作。這樣列表保持可掃讀詳情頁承接完整解釋。還要考慮字號放大和多語言。英文、數(shù)字、設(shè)備編號不一定有自然斷點布局壓力比中文更大。做國際化或系統(tǒng)字號適配時最好準(zhǔn)備一組極端數(shù)據(jù)作為 UI 回歸用例。如果團隊里經(jīng)常有人因為改文案把布局改崩我會把這些極端樣例直接做成假數(shù)據(jù)常駐在開發(fā)環(huán)境里。這樣每次改樣式時都能順手看到最壞情況而不是等測試階段才發(fā)現(xiàn)按鈕已經(jīng)被長標(biāo)題擠沒。異常文案要按信息優(yōu)先級讓位彈性布局不是讓所有內(nèi)容都完整顯示而是在空間不夠時保住最重要的信息。異常通知里狀態(tài)標(biāo)簽和操作按鈕通常必須可見標(biāo)題可以兩行省略輔助說明可以弱化或交給詳情頁承接。示例讓標(biāo)題使用layoutWeight(1)吸收剩余空間按鈕保持固定寬高狀態(tài)標(biāo)簽不參與伸縮。這樣長標(biāo)題不會把按鈕擠沒用戶仍然能完成處理動作。寫在最后測試時不要只放正常中文短句。英文長串、設(shè)備編號、異常碼、系統(tǒng)字號放大、多語言翻譯都會給布局制造壓力。能扛住這些異常文案卡片才算真正穩(wěn)定。