文案长度变化影响布局
别名: 文案撑版 · copy reflow · 措辞改布局
概念解释
界面文案不是贴在已经定稿的盒子上的标签，而是布局方程里的一个变量。文案撑版（copy-length reflow）指源语言定稿（或改稿）的字数、断行、语气词一变，按钮、标题、表格列、对话框高度就要跟着改。交付若按某一稿的长度锁死容器，下一稿文案不是「换几个字」，而是一次未声明的改版。
这里的变量是作者写的界面句子，不是用户数据的长短两端，也不是译成另一语言之后的膨胀。同一条产品句子从「删除」改成「永久删除此项目并无法恢复」，已经足够把页脚动作挤出安全区。
机制
布局在排版时测量的是塑形后的字形串。按钮的最小宽度跟着标签走，导航的换行跟着栏目名走，表格列宽跟着表头走。文案变长，先吃掉内边距，再逼出换行，换行再把下一行的控件往下推，于是「只改文案」变成一次重排。变短同样改结构：两个字的主按钮在一排动作里会显得像次要操作，短标题会让本该左对齐的页眉看起来像缺了内容。
顺序放大了损失。先锁布局再换文案，等于在已经浇筑的墙上开门；先定文案再锁盒子，改稿仍然会开门，但至少盒子声明过自己是可变的。交付把某一稿的长度当成几何常数，实现就会把 width: 120px 写进按钮，后续文案只能溢出或缩小字号——两者都不是文案作者想要的，却都是长度从未被当成变量的后果。
边界
图标按钮、只用符号的工具栏没有文案长度可走，这条管不到。固定字符数的系统代号（状态码、版本号作为标签）长度不变，按常数排即可。极窄的手表表盘、车机状态条本身就不能换行，文案作者必须在那一介质的字数上限内收束，而不是要求布局弹性。对话气泡、社交帖子以用户文本为主，作者文案只占页眉和动作；不要把用户文本的重排经验直接套到那两颗按钮上，它们的长度变化频率低得多，但一旦变化，命中区域和并排关系仍然会动。
怎么落地
- 把关键动作、导航、表头、错误句的容器标成「随文案变」，并写出允许的行数上限；只有确认必须单行的位置才锁高度。
- 文案改稿时同时出一帧新长度下的画面，不要只改文字图层而把旧的盒子留给实现。
- 在交付里附最短定稿和最长定稿各一版（仍是源语言、仍是作者文案），让实现看到按钮和对话框在两稿之间怎么走。
- 把文案表里最近一次改长的句子贴进已实现界面，看邻接动作是否仍完整可点、是否出现非预期换行。若实现拒绝改盒子、要求把句子改短去迁就旧布局，说明长度还没有被当成布局输入。