前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载本篇技术指南以开源仓库中的移动端排版参考文档 .agent/skills/mobile-design/mobile-typography.md 为骨架系统讲解移动端字体的设计基础、iOS/Android 系统字体体系、类型尺度、Dynamic Type 文本缩放、WCAG 无障碍要求、暗色模式排版以及字体加载性能优化。文中将结合 Dillinger 仓库实际的排版实现tailwind.config.ts、app/globals.css与自动化审计脚本 mobile_audit.py 进行纵深佐证。读完你能够为 iOS/AndroidReact Native、Flutter 或原生应用建立可缩放、可访问的排版体系并具备对现有实现做排版审计的能力。文档开宗明义地指出一个核心论断排版失败是移动应用不可读的第一大原因Typography failures are the #1 cause of unreadable mobile apps。移动端排版不是装饰而是用户与内容之间的主界面。1. 移动端排版基础为什么移动端与桌面端截然不同1.1 移动端字体的差异根源移动设备与桌面显示器的物理与交互环境存在本质差异这是移动端排版设计的第一性原理。文档给出了如下对比DESKTOP: MOBILE: ├── 20-30 viewing distance ├── 12-15 viewing distance ├── Large viewport ├── Small viewport, narrow ├── Hover for details ├── Tap/scroll for details ├── Controlled lighting ├── Variable (outdoor, etc.) ├── Fixed font size ├── User-controlled sizing └── Long reading sessions └── Quick scanning四条关键差异直接决定了设计决策观看距离更近12–15 英寸同样的字号在近距观看下看起来更大但同时也意味着用户对字体的清晰度更敏感抗锯齿与字重渲染质量要求更高视口更小更窄每行能容纳的字符数急剧下降正文行宽必须控制在 40–60 字符否则换行过于频繁、阅读追踪困难环境光照不可控用户可能在户外强光下使用低对比度文本会隐形因此对比度要求比桌面更严格AA 为底线AAA 更优字号由用户控制iOS 的 Dynamic Type 与 Android 的字体缩放85%–200%意味着开发者无法假定某个固定 px 值在用户设备上成立排版必须可缩放。1.2 移动端排版规则速查表规则桌面端移动端最小正文字号14px16px14pt/14sp最大行长75 字符40–60 字符行高1.4–1.51.4–1.6更宽松字重多样Regular 为主粗体克制使用对比度AA4.5:1AA 为最低要求AAA 优先移动端的核心心法是Regular 字重主导 粗体克制。从 Dillinger 的预览排版实现 app/globals.css 可以看到同样的思路正文font-size: 14px; line-height: 1.7标题统一使用font-weight: 600Semibold 而非更重的 Bold通过字号与行距而非字重爆炸来建立层级。2. 系统字体iOS 与 Android 的字体体系2.1 iOSSF Pro 家族iOS 的系统字体是 San FranciscoSF家族按用途分为五个子族San Francisco (SF) Family: ├── SF Pro Display: 大号文本≥ 20pt ├── SF Pro Text: 正文文本 20pt ├── SF Pro Rounded: 友好/趣味场景 ├── SF Mono: 等宽字体 └── SF Compact: Apple Watch、紧凑界面SF Pro 的核心特性光学尺寸Optical sizing字体根据实际渲染字号自动切换 Display/Text 形态保证大标题与正文各自的最优字面比例动态字距Dynamic tracking字母间距随字号动态调整大字号自动收紧、小字号自动放宽弥补大字号视觉上字距偏松的错觉表格/比例数字Tabular/proportional figures适合数据表格与正文两种场景出色的易读性Excellent legibility专为屏幕渲染优化。2.2 AndroidRoboto 家族Android 的系统字体是 Roboto同样是一个完整家族Roboto Family: ├── Roboto: 默认无衬线字体 ├── Roboto Flex: 可变字体variable font ├── Roboto Serif: 衬线选项 ├── Roboto Mono: 等宽 ├── Roboto Condensed: 窄空间Roboto 的特性针对屏幕优化Optimized for screens在低分辨率与 OLED 屏幕上都有良好表现广泛的语言支持Wide language support适合全球化应用多字重Multiple weights覆盖 100–900 全部字重小字号表现佳Good at small sizes小字号下笔画依然清晰可辨。2.3 何时使用系统字体决策清单✅ 应该使用系统字体的场景├── 品牌没有强制要求自定义字体 ├── 阅读效率是首要目标 ├── 应用需要原生/融为一体的感觉 ├── 性能是关键约束零下载成本 ├── 需要广泛的语言支持❌ 应避免系统字体的场景├── 品牌形象要求自定义字体 ├── 需要通过字体实现设计差异化 ├── 编辑/杂志风格editorial/magazine style └── 即便如此也必须支持无障碍缩放2.4 自定义字体的考量清单如果决定使用自定义字体必须逐项确认If using custom fonts: ├── 包含所有需要的字重Include all weights needed ├── 子集化以控制文件体积Subset for file size ├── 在所有 Dynamic Type 字号下测试Test at all Dynamic Type sizes ├── 提供系统字体回退Provide fallback to system ├── 测试渲染质量Test rendering quality └── 检查语言支持Check language support仓库佐证系统字体回退栈的工程化落地在 Dillinger 的 tailwind.config.ts 中字体族被定义为多层回退栈这正是自定义字体 系统字体兜底原则的 Web 端实现fontFamily: { sans: [Source Sans Pro, Helvetica Neue, Helvetica, Arial, sans-serif], serif: [Georgia, Cambria, serif], mono: [Ubuntu Mono, Monaco, monospace], },每个字体族的第一项是品牌自定义字体Source Sans Pro / Georgia / Ubuntu Mono随后紧跟平台原生字体Helvetica Neue / Monaco与通用字体族兜底。当自定义字体加载失败或缺失某字符时浏览器会平滑降级到系统字体用户依然能获得可读的排版——这与移动端自定义字体必须提供系统回退的要求完全同构。3. 类型尺度iOS、Material 3 与自定义模块化比例3.1 iOS 内建类型尺度Dynamic Type 文本样式iOS 提供 11 级内建文本样式随用户系统设置自动缩放样式字号字重行高Large Title34ptBold41ptTitle 128ptBold34ptTitle 222ptBold28ptTitle 320ptSemibold25ptHeadline17ptSemibold22ptBody17ptRegular22ptCallout16ptRegular21ptSubhead15ptRegular20ptFootnote13ptRegular18ptCaption 112ptRegular16ptCaption 211ptRegular13pt注意观察两个细节行高始终约为字号的 1.2–1.3 倍如 Body 17pt/22pt ≈ 1.29这与第 5 节无障碍行高的推荐一致同时标题字号从 34pt 到 17pt 逐级递减形成清晰的层级梯度。3.2 Android 类型尺度Material 3Material Design 3 定义了 15 个文本角色Text Role以 sp 为单位角色字号字重行高Display Large57sp40064spDisplay Medium45sp40052spDisplay Small36sp40044spHeadline Large32sp40040spHeadline Medium28sp40036spHeadline Small24sp40032spTitle Large22sp40028spTitle Medium16sp50024spTitle Small14sp50020spBody Large16sp40024spBody Medium14sp40020spBody Small12sp40016spLabel Large14sp50020spLabel Medium12sp50016spLabel Small11sp50016sp规律Display/Headline/Title/Body 四档以 400 常规字重为主Label 与 Title Medium/Small 使用 500 中字重以承担按钮、标签等功能性文本。3.3 自定义类型尺度模块化比例Modular RatioiOS 与 Android 的内建尺度覆盖了绝大多数场景但当品牌需要自定义尺度时应使用数学化的模块化比例生成字号而不是随手挑数值。推荐比例Recommended ratios: ├── 1.125 (Major second 大二度): 密集 UI ├── 1.200 (Minor third 小三度): 紧凑 ├── 1.250 (Major third 大三度): 均衡常用 ├── 1.333 (Perfect fourth 纯四度): 宽敞 └── 1.500 (Perfect fifth 纯五度): 戏剧化以 1.25 比例、16px 基准的完整示例├── xs: 10px (16 ÷ 1.25 ÷ 1.25) ├── sm: 13px (16 ÷ 1.25) ├── base: 16px ├── lg: 20px (16 × 1.25) ├── xl: 25px (16 × 1.25 × 1.25) ├── 2xl: 31px ├── 3xl: 39px └── 4xl: 49px仓库佐证模块化比例的姊妹文档仓库中另一份前端排版文档 .agent/skills/frontend-design/typography-system.md 系统阐述了同一原理选定基准字号正文通常 16–18px与比例移动应用常用 1.2 小三度、Web 常用 1.25 大三度然后用base × ratio^n生成整条尺度。这也印证了审计脚本对字号是否遵循模块化比例的检查逻辑见第 4 节 9.3 检查项。4. Dynamic Type 与文本缩放MANDATORY 强制要求4.1 iOS Dynamic Type必须使用语义化文本样式iOS 的 Dynamic Type 允许用户全局调整系统字号应用必须跟随这一设置。错误示范是写死固定字号// ❌ WRONG: Fixed size (doesnt scale) Text(Hello) .font(.system(size: 17)) // ✅ CORRECT: Dynamic Type Text(Hello) .font(.body) // Scales with user setting // 自定义字体也要声明相对尺度 Text(Hello) .font(.custom(MyFont, size: 17, relativeTo: .body))即使使用自定义字体也必须通过relativeTo:将其锚定到某个内建文本样式上才能随 Dynamic Type 缩放。4.2 Android 文本缩放必须使用 sp 单位Android 侧的唯一铁律是文本一律使用 spScale-independent Pixels。ALWAYS use sp for text: ├── sp Scale-independent pixels与缩放无关的像素 ├── 随用户字体偏好缩放 ├── dp 不缩放不要用于文本用户可将系统字体从 85% 缩放到 200%├── 默认100%: 14sp 14dp ├── 最大200%: 14sp 28dp必须在 200% 下测试布局一个 14sp 的文本在最大缩放时会占用 28dp 的空间固定高度的容器必然溢出。4.3 文本缩放带来的布局挑战与对策大字号下常见的问题Problems at large text sizes: ├── 文本溢出容器Text overflows containers ├── 按钮变得过高Buttons become too tall ├── 图标相对文本显得过小Icons look small relative to text ├── 布局崩溃Layouts break Solutions: ├── 使用弹性容器不要固定高度Use flexible containers ├── 允许文本换行Allow text wrapping ├── 图标随文本缩放Scale icons with text ├── 开发期间就在极端尺寸下测试Test at extremes ├── 长文本使用可滚动容器Use scrollable containers仓库佐证审计脚本如何自动检查缩放支持移动端审计脚本 .agent/skills/mobile-design/scripts/mobile_audit.py 的 4.2 检查项专门扫描 React Native 代码一旦检测到fontSize:存在但没有任何allowFontScaling: true/responsiveFontSize/useWindowDimensions缩放机制就会给出警告[Typography] {filename}: Fixed font sizes without scaling support. Consider allowFontScaling for accessibility.该脚本还检查行高上限lineHeight超过 1.8 会被标记对移动端过高、字号下限小于 12px 触发可读性警告与上限大于 32px 建议改用响应式缩放详见 mobile_audit.py。这意味着缩放支持不仅是设计原则还可以作为 CI 中可量化的审计项。5. 排版无障碍最小尺寸、对比度与行高5.1 最小字号表元素最小推荐正文Body text14px/pt/sp16px/pt/sp次要文本Secondary text12px/pt/sp13–14px/pt/sp注释Captions11px/pt/sp12px/pt/sp按钮Buttons14px/pt/sp14–16px/pt/sp任何内容不得小于11px-5.2 WCAG 对比度要求普通文本 18pt 或 14pt 粗体: ├── AA: 对比度 ≥ 4.5:1最低要求 ├── AAA: 对比度 ≥ 7:1推荐 大号文本≥ 18pt 或 ≥ 14pt 粗体: ├── AA: 对比度 ≥ 3:1最低要求 ├── AAA: 对比度 ≥ 4.5:1推荐 Logo/装饰性元素: 无要求5.3 无障碍行高WCAG 1.4.12 成功准则WCAG 对文本间距有明确的量化要求Line height行距: ≥ 1.5× 字号 Paragraph spacing段距: ≥ 2× 字号 Letter spacing字距: ≥ 0.12× 字号 Word spacing词距: ≥ 0.16× 字号移动端推荐值├── 正文: 行高 1.4–1.6 ├── 标题: 行高 1.2–1.3 ├── 任何文本不得低于 1.2仓库佐证Dillinger 预览排版的行高实践在 app/globals.css 中Dillinger 的 Markdown 预览正文设置了line-height: 1.7高于 WCAG 的 1.5 下限、落入移动端推荐区间1.4–1.6 之上适合长文阅读标题则通过margin-top: 1.5em; margin-bottom: 0.5em保证段落间距达到 2× 字号的量级对应 WCAG 段距要求。这种正文宽松、标题紧凑的层次与移动端推荐完全一致。6. 暗色模式排版6.1 颜色调整原则Light Mode: Dark Mode: ├── 黑色文本 (#000) ├── 白色/浅灰文本 (#E0E0E0) ├── 高对比度 ├── 略降低的对比度 ├── 全饱和度 ├── 去饱和的颜色 └── 深色 强调 └── 浅色 强调铁律暗色模式下不要使用纯白#FFF。应使用介于 #E0E0E0 到 #F0F0F0 之间的米白off-white来减轻眼部疲劳。6.2 暗色模式层级色表层级亮色模式暗色模式主文本Primary text#000000#E8E8E8次文本Secondary text#666666#A0A0A0三级文本Tertiary text#999999#707070禁用文本Disabled text#CCCCCC#5050506.3 暗色模式下的字重策略暗色背景下文本会因**光晕效应halation浅色光渗入深色背景**而显得更细因此需要Consider: ├── 正文使用中字重medium替代常规字重regular ├── 略微增加字母间距letter-spacing ├── 在真实 OLED 屏幕上测试 └── 使用比亮色模式略粗的字重仓库佐证Dillinger 暗色排版的落地细节Dillinger 在 app/globals.css 中为暗色预览定义了.dark.preview-html { color: #d4d4d4; }——注意它不是纯白 #FFFFFF而是接近文档推荐的 #E0E0E0 区间直接呼应暗色模式禁用纯白的规则。标题颜色 #e8e8e8、链接保持品牌色 #35D7BB、代码块背景 #2d2d2d 且前景 #d4d4d4均体现了降低对比但不牺牲可读性的暗色排版策略。项目通过darkMode: classtailwind.config.ts按类切换暗色样式移动端对应useColorScheme的系统外观监听。7. 排版反模式常见错误与 AI 特有错误7.1 常见错误对照表错误问题修复固定字号Fixed font sizes无视无障碍使用动态缩放文本过小Too small text不可读最小 14pt/sp低对比度Low contrast阳光下不可见最小 4.5:1过长行Long lines难以追踪最大 60 字符行高过紧Tight line height拥挤、难读最小 1.4×字号过多Too many sizes视觉混乱最多 5–7 个字号正文全大写All caps body难读仅用于标题白底浅灰Light gray on white强光下不可读提高对比度7.2 AI 生成的排版为何经常出错AI 生成移动端代码时存在系统性倾向AI tends to: ├── 使用固定 px 值而非 pt/sp ├── 跳过 Dynamic Type 支持 ├── 正文过小12–14px ├── 忽略行高设置 ├── 使用低对比度的审美灰 ├── 将桌面尺度原样套用到移动端 └── 跳过在大字号下的测试最终规则排版必须可缩放Typography must SCALE在最小与最大字号设置下都要测试。仓库佐证审计脚本对 AI 反模式的机器化识别mobile_audit.py 的 9.x 扩展检查组几乎逐条对应上述反模式9.1 检查字号是否偏离 iOS 类型尺度、9.2 检查 Material 排版是否使用 sp 单位、9.3 检查字号是否遵循模块化比例识别 1.125/1.2/1.25/1.333/1.5 之外的异常比率、9.4 检查长文本是否缺少最大宽度约束对应 40–60 字符行宽、9.5 检查粗体是否过度使用bold 数量多于 regular 会被标记。这让排版反模式检查具备了自动化落地手段。8. 字体加载与性能8.1 字体文件体积优化字体文件在移动端是明显的性能负担Font file sizes matter on mobile: ├── 完整字体: 每个字重 100–300KB ├── 子集化拉丁文: 每个字重 15–40KB ├── 可变字体: 100–200KB覆盖全部字重推荐做法├── 子集化到需要的字符Subset to needed characters ├── 使用 WOFF2 格式 ├── 最多 2–3 个字体文件 ├── 考虑可变字体variable fonts ├── 合理缓存字体8.2 加载策略四步法1. SYSTEM FONT FALLBACK系统字体回退 先显示系统字体 → 自定义字体加载完成后替换 2. FONT DISPLAY SWAP font-display: swapCSS 声明 3. PRELOAD CRITICAL FONTS预加载关键字体 预加载首屏above the fold需要的字体 4. DONT BLOCK RENDER不要阻塞渲染 不要为了等字体而延迟内容显示仓库佐证零字体加载开销的 Web 端策略Dillinger 作为一个以编辑效率为核心的应用其 tailwind.config.ts 声明的字体栈首项Source Sans Pro、Georgia、Ubuntu Mono即使未能加载也会立即回退到系统字体天然实现了系统字体先行、自定义字体渐进增强的策略——这正是不阻塞渲染 系统回退在 Web 平台的等价实现。对移动端开发者而言这条策略对应 SwiftUI 的.font(.custom(..., relativeTo: ...))与 Compose 的FontFamily回退参数。9. 发布前排版检查清单9.1 任何文本设计开始之前正文 ≥ 16px/pt/sp行高 ≥ 1.4行长 ≤ 60 字符定义了类型尺度最多 5–7 个字号使用 ptiOS或 spAndroid9.2 发布之前iOS Dynamic Type 已测试Android 在 200% 字体缩放下已测试暗色模式对比度已检查阳光下可读性已测试所有文本都有正确的层级自定义字体有回退方案长文本可正常滚动落地建议把清单变成自动化审计仓库提供的 mobile_audit.py 可以帮你把大部分检查项自动化。其用法见脚本 main 函数为python scripts/mobile_audit.py project_path # 输出人类可读报告 python scripts/mobile_audit.py project_path --json # 输出 JSON 报告便于 CI 集成脚本自动识别 React Native / Flutter 文件通过 import 特征跳过 node_modules 等目录输出 ISSUES硬性问题如 ScrollViewmap、缺 keyExtractor、明文存 token与 WARNINGS建议项如固定字号无缩放、缺 React.memo、无暗色模式支持两级报告其中排版相关检查覆盖系统字体、文本缩放、行高、字号边界、模块化比例、行宽与字重分布脚本头部注释 mobile_audit.py 列出了完整的检查矩阵。退出码非零即表示存在硬性问题可直接挂入 CI 门禁。10. 快速参考10.1 排版令牌Typographic Tokens// iOSSwiftUI 内建样式 .largeTitle // 34pt, Bold .title // 28pt, Bold .title2 // 22pt, Bold .title3 // 20pt, Semibold .headline // 17pt, Semibold .body // 17pt, Regular .subheadline // 15pt, Regular .footnote // 13pt, Regular .caption // 12pt, Regular // AndroidMaterial 3 文本角色 displayLarge // 57sp headlineLarge // 32sp titleLarge // 22sp bodyLarge // 16sp labelLarge // 14sp10.2 最小字号速查Body: 14–16pt/sp推荐 16 Secondary: 12–13pt/sp Caption: 11–12pt/sp 任何文本: 不得小于 11pt/sp10.3 行高速查Headings: 1.1–1.3 Body: 1.4–1.6 Long text: 1.5–1.75结语排版即界面原文档在结尾给出了移动端排版设计的最终判据如果用户读不懂你的文本你的应用就是坏的。排版不是装饰——它是主界面Typography isnt decoration—its the primary interface。要在真实设备、真实光照、无障碍设置开启的状态下测试。将这份指南落到 Dillinger 仓库的语境中可以看到一条完整的证据链设计文档 mobile-typography.md 定义原则 → 前端排版文档 typography-system.md 给出模块化比例的生成方法 → 审计脚本 mobile_audit.py 将原则量化为可自动执行的检查 → Web 端实现 tailwind.config.ts 与 app/globals.css 提供了系统字体回退栈 宽松行高 暗色米白文本的真实范例。无论你正在构建 React Native、Flutter 还是原生应用都可以以此为模板定义类型尺度 → 锚定系统缩放 → 通过审计 → 在极端字号下测试让排版真正成为用户可读、可缩放、可访问的界面基础设施。赞分享前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载相关推荐ag-kit 移动排版完全指南Type Scale、系统字体、Dynamic Type、深色模式与可访问性验证ag kit 移动排版完全指南Type Scale、系统字体、Dynamic Type、深色模式与可访问性验证 本篇技术指南以 ag kit 技能库中 mob人工智能AI 技能Logoly无障碍字体选择确保可读性与可访问性的字体Logoly无障碍字体选择确保可读性与可访问性的字体 在数字产品设计中字体选择不仅关乎视觉美感更是确保所有用户包括残障用户能够有效获取信息的关键环节。前端mailcheck.js无障碍字体选择提升可读性mailcheck.js无障碍字体选择提升可读性 引言 在当今数字化时代网页的可访问性Accessibility简称A11y日益受到重视。对于邮件验证开发工具上一篇Windows窗口置顶神器3分钟解锁高效多任务工作流下一篇猫抓插件终极教程三步轻松下载网页中的任何视频资源创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考