用户把手机字体调大，App 里的按钮和金额就叠在一起了，先加个「大字模式」开关能行吗？

结论：用户把系统字体调大后 App 界面错位，多数不是缺一套「适老化版本」，而是布局里用了固定字号、固定高度和单行截断，没给文字留伸缩余量。按 2026 年项目交付经验，字体缩放要同时过原生布局、H5 页面、第三方 SDK 三层；只加一个大字号主题，通常只能盖住首页，进到列表、弹窗和支付页还会乱。适合已有 App 收到适老化反馈、或要过应用商店适老化评测的场景。

先分清：系统字体缩放，还是 App 内字号设置

很多团队把两件事混在一起：一是用户在手机系统设置里把字体调大，二是 App 内部自己做一套大/中/小字号。前者影响所有跟随系统字体的应用，后者只影响自己。如果 App 用固定 dp/pt 写字号，系统字体调大它不会跟随，用户会觉得「调了没用」；如果 App 跟了系统字体但布局没弹性，字一大就叠在一起，用户又会觉得「适老化做坏了」。

• Android：字号建议用 sp 而不是 dp，布局高度避免写死，让文字能撑开容器。
• iOS：常用 Dynamic Type 和 preferredFont，配合 adjustsFontForContentSizeCategory。
• H5：root font-size 和 rem 会影响缩放效果，固定 px 宽度在字体放大后容易横向溢出。
• 第三方 SDK：地图、支付、客服、统计弹窗多数不跟随系统字体，属于常见盲区。

判断标准很简单：把系统字体调到常见的大号档位后，核心页面文字不截断、按钮不重叠、列表行高自动撑开。做到这三点，才算过了第一关。

三层字体伸缩检查法

按 2026 年项目交付里的常见做法，字体缩放可以拆成原生布局层、H5 与内嵌页层、第三方 SDK 层。三层字号来源不同：原生层自己可控，H5 层受 WebView 和 CSS 影响，第三方层基本由外部决定。混在一起查，容易只改了首页就以为做完了。

1. 原生布局层：检查字号单位、固定高度、单行截断和约束优先级。合格线是文字放大后按钮高度自动撑开，不压到下一行。优先改布局弹性，不要为了适配把所有字号写死。
2. H5 与内嵌页层：检查 rem 基准、viewport、固定 px 宽度和表格横向滚动。合格线是字体放大后页面可读，不出现横向溢出覆盖。H5 与原生字号体系要提前对齐。
3. 第三方 SDK 层：地图、支付、客服、统计弹窗等通常不跟随系统字体。合格线是至少做到不遮挡、不崩溃，必要时用应用内独立字号或原生壳层兜底。

这三步的顺序建议从原生到 H5 再到第三方，因为原生层改完，H5 和第三方的真实问题才更容易暴露。不要跳过任何一层，否则上线后总有一类页面被用户先发现。

字体适配合格线怎么定？验收口径

验收不能只截图看首页。按项目交付习惯，要在系统字体的默认、大、特大几个档位下，各过一遍核心链路：登录、列表、详情、表单、支付和弹窗。每个档位都记一次问题，最后按清单修复，而不是凭感觉挑几个页面看。

• 文字不截断：标题、按钮、金额、状态至少完整显示，或允许换行。
• 控件不重叠：按钮、输入框、图标之间保持可点区域，不互相压盖。
• 行高自动撑开：列表项高度随文字增加，不压住相邻项。
• 弹窗不溢出：确认弹窗、权限说明、协议页文字放大后可滚动到底。
• 第三方页不崩：支付、地图、客服页面至少可用，不因字体放大闪退。

一个常见反例是：只把首页截图发给客户看，说适老化做完了，结果上线后订单页按钮文字被截断。合格不是「首页好看」，而是核心业务链路在放大字体下仍能走通。

跟随系统、应用内独立字号、局部放大，怎么选？

2026 年常见做法有三种，不是越全越好，要看 App 的类型和用户预期。对比时重点看四个维度：实现成本、覆盖范围、用户预期和维护成本。

• 跟随系统字体：成本中等，原生页面覆盖好，但 H5 和第三方 SDK 常跟不上；适合大多数工具、政务、金融类 App。
• 应用内独立字号：成本较低，只影响自己的页面，用户会理解为 App 自己的阅读设置；适合内容阅读类，但系统字体调大时可能仍不跟随。
• 只在特定页面放大：成本最低，适合只改首页或帮助页；但用户进到其他页面会感觉不一致，容易反复提意见。

经验区间：一个已有中等复杂度 App 做完整字体伸缩检查，常见区间是 3 到 10 人日；如果布局大量写死、H5 页面多，可能到 2 到 4 周。预算按实际改动量评估，不建议按整套重置报价。

适用与不适用边界

字体缩放适配适合已经有明确用户反馈或评测要求的项目。如果应用商店有适老化、无障碍评测，或者行业本身对可访问性有要求，就建议排进迭代清单；如果用户反馈集中在「字体调大后看不清、点不到、文字叠一起」，那基本可以确认要查布局弹性。

• 适合做：政务、金融、医疗类 App，或用户年龄跨度大的工具、内容类 App。
• 适合做：已有 App 迭代，布局里用了较多固定高度和单行文本，且用户反馈集中。
• 不必上：纯内部工具、用户量很小且明确不调系统字体的场景。
• 不必上：以视频或游戏为主、界面文字极少的 App，优先保证画面比例。
• 不必上：还在原型阶段、页面没定稿，先按弹性布局习惯写，不必单独做一套大字号主题。

边界句：字体缩放适配的投入通常集中在布局弹性改造，而不是做第二个 App；如果原布局大量写死高度，改造成本会明显高于新项目直接按弹性布局写。所以新项目一开始就避开固定高度，往往比上线后再改更省。

交付现场常卡住的几个坑

在项目里常见，甲方卡在「系统字体调大后只测了首页」。做法通常是先按三层清单跑一遍，结果发现订单页按钮高度写死、H5 弹窗宽度固定，返工集中在布局层而不是字号层。代价是上线后用户投诉集中，改稿和发版次数增加，严重时还要走紧急热修复。

• 固定高度写死：按钮 height 固定，文字放大后直接溢出。
• 单行省略：ellipsis 遇到放大文字会截断关键信息，金额和状态尤其明显。
• H5 用 px 写死宽度：字体放大后横向滚动或覆盖其他元素。
• 只改字号不改行高：文字变大、行距不变，阅读时挤在一起。
• 忽略第三方页：支付、地图、客服页面不跟随系统字体，放大后遮挡操作区。
• 忘记测弹窗：协议和权限说明放大后无法滚动到底部，用户点不到确认。

交付现场经验：曾对接一个政务类 App，适老化评测前两周才收到反馈，约束是页面多、排期紧。做法是先跑三层清单，优先改原生弹性布局和行高，H5 用 rem 调基准，支付页做原生壳层兜底；结果核心链路在大号字体下可用，代价是额外花了约 5 人日，发版排期往后挪了几天。这里经验区间是：只改核心页常见 3 到 10 人日，全量改造可能到 2 到 4 周。

常见问题

用户只在系统设置里把字体调大，App 不跟随，是不是必须做适老化版？

不一定。先看 App 用的是 sp/动态字体还是固定 dp/pt；如果代码里字号写死，改成跟随系统字体通常比单独做一套大字号主题更省事，也不影响原有外观。

App 内已经有大/中/小字号设置，还需要跟系统字体吗？

常见做法是两者不冲突：应用内设置管 App 自己的阅读体验，系统字体管全局可访问性。若应用内设置完全覆盖系统字体，适老化评测时可能被认为未跟随系统。

字体放大后，H5 页面和第三方 SDK 页面也要一起改吗？

H5 能通过 rem、viewport 和弹性布局改善，第三方 SDK 多数不跟随系统字体。合格线是放大后不遮挡、不崩、可滚动，而不是强行让所有第三方页都变大。

适老化字体适配一般要留多少工期和预算？

经验区间：只做核心页面检查和弹性布局调整，通常 3 到 10 人日；若原布局大量写死高度、H5 页多，可能到 2 到 4 周。预算按改动量评估，不建议按整套重置报价。

新项目怎么一开始就少踩字体缩放的坑？

新项目按弹性布局写：字号用可缩放单位、避免固定高度、列表行高自适应、H5 用相对单位。交付前把系统字体调到大号过一遍核心链路，比上线后返工便宜。

如果 App 已经上线，先用三层清单在系统字体大号档位下过一遍登录、列表、详情、支付四条链路，把问题记成清单再评估改动量。字体缩放适配适合有适老化要求或用户集中反馈错位的项目；纯内部工具、极简文字界面不必强行上全套，优先保证核心链路可用即可。需要落地时，可按官方文档和交付验收清单逐项核对。