| 1. 国家城市 | 硬编码国家/地区和城市，新开国/新开城时无法自适配。 | 使用HK、CN、810001等硬编码。 | 从业务实体（如用户Profile）获取国家/地区、城市信息。 | 中 |
| 写死的region/city兜底影响货币、时间等i18n元素计算，存在资损风险。 | DB建表语句默认值含DEFAULT 'HK'；代码使用“HK”或“810001”兜底。 | 评估是否需要兜底，对异常命中兜底的情况进行监控报警。 | 中 |
| 2. 语言文案 | 硬编码语言设置，忽略用户偏好，导致理解障碍。 | 使用zh-HK、en、zh等硬编码语言标识。 | 从公共参数（公参）获取用户实际选择的语言。 | 中 |
| 兜底语言非英语，导致用户无法看懂。 | 终端i18n-sdk设置兜底语言为zh-HK等非英语。 | 将兜底语言设置为en（英语）。 | 中 |
| 代码硬编码文案，无法适配多国语言。 | 代码中直接写入显示文案（字符串）。 | 接入翻译平台，使用key来维护和获取多语言文案。 | 中 |
| 3. 货币 | 硬编码币种/符号，新开国时无法自适配。 | 代码使用"HKD"、"HK$"、"港币"等硬编码。 | 根据业务实体获取币种，或使用I18N-SDK格式化货币函数。 | 中 |
| 主辅币比例硬编码1:100，导致金额计算错误（如日本、科威特）。 | BigDecimal方法、100常量（100.0, 100L）、乘除100的运算。 | 使用I18N-SDK进行主辅币转换，获取动态比例。 | 高 |
| 货币小数位数硬编码2位，导致舍入误差（如科威特第纳尔）。 | AI分析代码中对金额小数位数的限制（如保留2位）。 | 使用I18N-SDK获取货币对应的小数位数。 | 中 |
| 4. 时间 | 日期计算硬编码86400s/24h，夏令时国家计算错误。 | 代码使用86400（秒）或24（小时）等硬编码时间常量。 | 使用I18N-SDK提供的日历函数进行日期加减。 | 中 |
| 时区硬编码，多时区国家时间展示错误。 | 时区使用CST、GMT、Asia/Hong_Kong等硬编码标识。 | 根据cityId处理时间，业务逻辑无需感知具体时区。 | 中 |
| 固定使用首都时区，多时区国家时间错误。 | 获取首都时区进行时间处理；定时任务按国家而非城市触发。 | 根据用户/商家/骑手所在的具体城市来处理时间。 | 中 |
| 时间格式硬编码，不符合地区习惯。 | 使用固定的格式字符串，如yyyy-MM-dd HH:mm:ss。 | 使用I18N-SDK的时间格式化函数，自动适配地区格式。 | 中 |
| 时间Pattern误用大写Y（表示“Week of Year”），导致年展示错误。 | 正则匹配模式中的大写字母Y。 | 在表示年份时改用小写y。 | 中 |
| 时间Pattern误用小写hh（12小时制），应改为HH（24小时制）。 | 正则匹配模式中的"hh"。 | 在表示24小时制的小时时改用大写的"HH"。 | 中 |
| 使用原生Java时间函数，导致硬编码格式或时区数据错误。 | 使用java.text.SimpleDateFormat，java.util.Calendar， java.util.TimeZone，java.time.format.DateTimeFormatter，java.time.ZoneId，java.time.OffsetDateTime，java.time.ZonedDateTime | 统一使用I18N-SDK提供的时间处理函数。 | 中 |
| 5. 度量衡 | 硬编码单位，新开国/新开城无法自适配。 | 使用"km"、"m"、"千克"、"斤"等硬编码单位。 | 使用I18N-SDK的度量衡单位获取和格式化函数。 | 中 |
| 6. 电话 | 电话区号硬编码，无法自适应开国。 | 使用"852"、"966"、"+86"等硬编码区号。 | 使用I18N-SDK的区号获取函数。 | 中 |
| 7. 通用 | 使用SDK废弃函数，导致新开国时间异常。 | 调用已标记为@Deprecated的SDK函数（常见于时间格式化）。 | 查阅SDK文档，改用新的替代函数。 | 中 |