总部把用了两年的心理测评系统推给欧洲和东南亚分部时，卡住的不是功能，而是两类容易被忽略的底层设置：时区和语言包。这两项配错，测评照样能提交，但提醒发错时间、报告时间戳对不上、翻译后的量表失去参照价值，运营方要过很久才发现。
时区：存储用 UTC，展示按分部本地
系统内部的时间戳应统一按 UTC 存储，展示层再按机构或用户所在时区换算。如果直接把总部本地时间写进数据库，跨三四个时区的分部一算就偏。定时任务受影响最明显：批量发放的截止时间、复测提醒、报告生成时间，如果绑定在总部时区，欧洲员工会在凌晨收到提醒，答题窗口也会提前关闭。
配置时把时区拆成两层。机构层给每个分部设默认时区，用户层允许外派员工临时覆盖。提醒类任务按“本地上午九点”这类相对规则触发，而不是写死一个绝对时刻。跨天的截止时间要标清以哪个时区为准，避免“周五 24 点截止”在不同分部差出一整天。
语言包：界面能翻，量表不能随便翻
界面文案、按钮、邮件模板这些走语言包切换没有争议。真正的坑在量表本身。一份量表翻译成另一种语言，不等于在当地可用：常模是按原语言、原文化人群建立的，直接套用会让分数失去参照意义。计分逻辑没变，但结论的解释边界变了。
可行的做法是区分两类文本。产品界面按分部语言即时切换；量表只使用已有官方本地化版本或明确标注的授权译本，并单独维护每个版本对应的常模来源。没有可靠本地化版本的量表，宁可在该分部暂不启用，也不要用机器翻译临时凑。知情同意书、隐私说明这类涉及合规的文本，必须按当地语言和当地法规单独出一份，不能只译总部版本。
容易漏的细节
字符编码统一用 UTF-8，覆盖越南语、泰语的声调符号和德语变音字符，否则报告导出会出现乱码。日期格式按地区显示，年月日顺序在不同国家不一样，混用会让答题人误填。语言回退要有默认值，某段文案缺译时回退到英文，而不是显示空白或键名。
上线前怎么验收
外派一个测试账号到目标分部，检查三件事：提醒是否在当地设定时间到达，报告页时间戳与本地时间一致，切换语言后没有残留未翻译的键名。再挑一份该分部要用的量表，确认它绑定的是本地化版本和对应常模，而不是总部默认版本。这几项通过，橙星云这类多分部部署才算真正能用，而不只是界面看着像本地化。