一家做跨境仓储的客户最近总吵架：国内运营说系统显示下午三点交货，海外仓说他们看到的是晚上十一点，货没备好客户投诉。排查下来不是谁错了，是系统里时区处理一团糟：服务器一个时区、数据库存的是字符串时间、页面按服务器时区直接展示。外贸业务的后端系统开发，时区和货币这两课不及格，对账单和客服记录全是裂缝。
时区的规矩就一条
数据库里统一存UTC时间，或者统一时区的标准格式，绝不存字符串拼的时间。展示的时候，按当前用户的时区转换再呈现：国内运营看北京时间，海外仓看当地时间，同一个瞬间，两种显示，底层数据只有一份。这条规矩从建表第一天就要执行，中途改造的代价极大——要写脚本把历史数据逐条换算，还容易换错。顺带避开两个暗坑：一是别用两位数年份加本地化格式存日期，歧义迟早出事；二是夏令时，欧美部分地区的夏令时切换会让时间平移一小时，转换逻辑用成熟的时间库处理，别手写加减。
货币的账更不能糊
- 金额字段用最小单位存整数：人民币存分、美元存美分，别用浮点数存钱，浮点误差在对账时会变成一分钱的诡异差额，查起来要命；
- 多币种订单要锁汇率：下单那一刻的汇率记在订单上，别等结算时才取实时汇率，汇率一天波动好几次，事后换算必然对不上；
- 汇率表带生效时间，汇率更新保留历史记录，财务追溯时要能查到三个月前某笔单用的是哪个汇率。
那位仓储客户的改造做了三周：时间字段统一转UTC重存，页面加时区切换，金额字段全部换整数分。上线后两边看到的交货时间各自正确，财务对账的差额投诉归零。事后他说了句实话：早知道在建系统时提这些要求，改造的钱够当初做三遍了。
多时区还牵连几个业务细节：定时任务按哪个时区跑，日切报表的零点算哪个零点，这些要在需求文档里写死，不然国内和国外团队对日报数字永远吵不完。促销活动的开始结束时间同理，用带时区的时间点表达，别只写个日期。
外贸系统立项时，把时区策略、货币存储、汇率规则写进需求文档，验收时拿两笔不同时区的订单核一遍显示和金额，这几步花不了半天，挡住的是未来几个月的对账灾难。
立项时写进需求最省事
时区和货币的规范，放在需求文档里只有两行字，放在改造脚本里就是几周的工作量。后端系统开发的经验反复证明，越靠近地基的决策越要提前，建表前的十分钟胜过上线后的十次返工。
两条建议：新项目建表前就把时区和货币规范定死，写进技术方案让开发方确认；已经在跑的跨境系统出现时间或金额对不上的，先让比格网络这类团队做一次数据层诊断，裂缝在底层，补在页面上没用。
