先把底层逻辑说透
zh是语言，Hans和Hant是文字体系，CN、TW、HK、SG是地区。你可以把它们想成三层标签：用户说什么语言、页面用什么字、内容服务哪个市场。大多数zh避坑，都是因为这三层被揉成了一坨。
BCP 47这套语言标签规则在网页、系统、浏览器里用得很广。它允许zh-Hans、zh-Hant、zh-CN、zh-Hant-HK这类组合。写得越具体，承诺越多；写得越粗，兼容越宽，但表达也越模糊。
zh避坑：语言代码别乱写
zh避坑的核心不是背标准，而是搞清楚“语言、文字、地区”三件事别混用。很多项目上线时看不出问题，等到加繁体、做SEO、接第三方翻译平台，早期随手写的zh、cn、zh_CN就会变成一串隐形债。
坑一：把cn当中文
cn不是中文，它是中国的国家代码。很多团队为了URL短，喜欢/en、/cn这样配。做市场页问题不大，但一旦拿这个值去填lang、hreflang或翻译key，就开始不对劲。
实际处理建议很简单：URL市场路径可以保留/cn/，但页面HTML里写lang="zh-CN"，站点地图和hreflang也用zh-CN。内部系统最好把language和region拆字段，别用一个locale字段装所有含义。
坑二：只用zh覆盖所有中文
单写zh省事，但它没法区分简体和繁体。早期只有一个中文版本还行，后面加台湾繁体时，老页面、缓存、翻译记忆库、SEO标注都会纠缠在一起。
我更喜欢的做法是：只要你确定内容是简体，就从第一天用zh-Hans或zh-CN；确定繁体就用zh-Hant或具体地区。哪怕目前只有一版，也给未来留个清楚的台阶。
坑三：下划线和横线混着来
工程里常见zh_CN，网页标准里常见zh-CN。两个长得差不多，但不是同一个语境。Java、Linux locale里下划线多，HTML、hreflang、BCP 47里横线多。
别靠人工记忆硬扛。最好在项目里定一条转换规则：存储用统一格式，比如zh-CN；接入老系统时再转成zh_CN。这样日志、翻译文件、前端路由不会各写各的。
坑四：地区化内容只换字体
繁简转换不是本地化。大陆说“账号”，台湾常见“帳號”；大陆说“手机”，香港页面可能写“手提電話”或直接混英文。支付、发票、隐私政策更不能只做字形转换。
如果你用了zh-TW或zh-HK，最好检查至少五类内容：货币、地址、客服时间、法律条款、常用产品词。代码越具体，用户越会期待你真的懂当地语境。
收回来：一个稳妥配置
新项目可以按这个顺序定：先问有没有简繁差异，再问有没有地区差异。只有简体用zh-Hans，简体且大陆专属用zh-CN；只有繁体用zh-Hant，台湾专属用zh-TW，香港专属用zh-HK。
这套zh避坑思路不花哨，但很耐用。它的价值在于让代码、内容、搜索引擎和用户预期对齐。后面你接翻译平台、做站群、拆市场页，都会轻很多。
常见问题
- zh避坑最先要检查哪里？
- 先查HTML lang、hreflang、URL路径、翻译文件名四处。它们如果混用zh、cn、zh_CN，后面最容易出脏数据。
- zh_CN一定是错的吗？
- 不一定。它在某些系统locale里是正常写法，但放到HTML lang和hreflang里应改成zh-CN。关键看使用场景。
- 简体中文用zh-Hans还是zh-CN更好？
- 面向所有简体用户用zh-Hans；内容明显是中国大陆市场，比如人民币、ICP备案、国内物流，用zh-CN。