数字、日期与计量单位应采用用户所在地区的惯例
别名: 本地格式 · 日期格式 · 计量单位 · 歧义日期
概念解释
数值、日期、时间、货币、地址、电话、名称顺序和计量单位应按用户地区与业务场景呈现。地区惯例（locale conventions）决定 03/04/2026 是三月还是四月、千位分隔符是小数点还是分组符、距离用公里还是英里。这一条和组内前三条的关系是：前三条管的是词汇和隐喻这类"用户能立刻意识到自己看不懂"的匹配问题，这一条管的是最危险的一类不匹配——数字和日期格式即使读错了，读者往往也毫无察觉，因为读错之后得到的仍然是一个合法的值。
机制
格式类错误之所以比其他不匹配更危险，是因为它很少表现为"看不懂"，而是表现为"看懂了，但看懂的是另一个意思"。03/04/2026 无论按月/日/年读还是按日/月/年读，得到的都是一个真实存在、语法完全合法的日期，系统的格式校验不会报错，用户自己也不会意识到有歧义——错误因此不会在输入的那一刻被拦下，而是原样流入下游，直到它在跟其他系统或其他人的记录发生冲突时才会暴露，而这时候已经很难追溯回最初那次格式误读。这条机制解释了为什么日期和数字的本地化不能被当成一个纯粹的视觉本地化问题：拼写错误会被校验拦住，格式误读不会，它伪装成一个完全正常的答案潜伏下去。
边界
不是所有场合都按个人地区显示，也不是所有用户的日历系统都是公历。国际合同、航空时刻、科学数据和金融交易可能需要 ISO 8601、UTC、三位小数或双单位显示，这类场景应明确标注格式标准而不是隐式依赖用户猜测。地区惯例也不止公历地区内部的格式差异这一个维度：部分地区的用户日常使用非公历纪年（例如佛历、伊斯兰历）或非阿拉伯数字书写系统，界面若只按公历、阿拉伯数字设计"本地化"，对这部分用户仍然是外来格式。反过来，有些场景必须刻意打破"跟随用户地区"这条默认规则——医疗剂量、工程规格这类关乎安全的数值，即使显示给习惯英制单位的用户，也应该在关键记录里保留公制数值并标注清楚单位，因为不同背景的医护或工程人员之间传递数据时，统一单位比迎合个人习惯更重要，这时候"匹配用户世界"要让位给"匹配跨角色协作安全"。
怎么落地
- 建立格式层：地区、语言、货币、日历、时区、单位和数字精度分离存储与展示，展示层可以切换，但存储层必须保留无歧义的规范值（如 ISO 8601 日期、公制数值加单位标注）。
- 输入支持本地格式并即时回显解释结果，例如用户输入
03/04/2026后立刻在旁边显示"即 2026 年 3 月 4 日"，让用户在提交前就能发现系统解析得对不对；日期存在歧义的场合优先用月份名或日历控件，从入口处直接消除歧义而不是依赖回显纠错。 - 涉及安全或跨角色协作的数值（剂量、工程公差、合同金额），无论展示层如何本地化，都在旁边保留一份无歧义的规范格式，供不同背景的人核对。
- 验证办法：用目标地区的真实样本数据测试输入、排序、导出、打印和屏幕阅读器朗读这五个环节，尤其检查排序和导出——这两处最容易在格式转换时把日期和数字当成字符串处理，产生视觉上正确但排序或计算错误的结果。