strptime() 解析中文月份失败主因是系统 locale 不一致，而非格式错误；应优先用字典映射替代 locale 依赖，避免全局 setlocale 带来的线程与跨平台风险。
Python 的 datetime.strptime() 解析失败，大概率不是格式写错了，而是系统 locale 搞的鬼。
为什么 strptime() 在某些机器上突然不认中文月份？
它默认依赖系统 locale 设置解析月份、星期等本地化字符串。比如 datetime.strptime("二月", "%B") 在中文环境可能成功，在英文环境直接抛 ValueError: time data '二月' does not match format '%B'。
- 不是 Python 版本问题，是运行时环境差异
-
%B、%A这类格式符会查当前 locale 的语言表，不是硬编码中文 - Docker 容器、CI 环境、Mac 和 Linux 默认 locale 常不一致，最容易踩坑
用 locale.setlocale() 强制设中文就安全了？
不安全。它改的是全局 locale，会影响整个进程里所有依赖 locale 的操作（比如 sorted()、string.capwords()），还可能在多线程下引发竞态。
- 必须配对调用
locale.getlocale()保存旧值，再恢复 —— 很容易漏 - Windows 上 locale 名字和 Linux 不同（
Chinese_China.936vszh_CN.UTF-8），跨平台难维护 - 部分容器镜像压根没装中文 locale 包，
setlocale()直接报locale.Error
更稳的解法：绕开 locale，用字典映射
对确定的中文/日文/韩文月份、星期，自己建个映射表，把字符串转成数字再喂给 datetime 构造器，完全不碰 locale。
CHINESE_MONTHS = {
"一月": 1, "二月": 2, "三月": 3, "四月": 4,
"五月": 5, "六月": 6, "七月": 7, "八月": 8,
"九月": 9, "十月": 10, "十一月": 11, "十二月": 12
}
<p>def parse_chinese_month(s):
for k, v in CHINESE_MONTHS.items():
if k in s:
return v
raise ValueError(f"无法识别月份: {s}")</p><h1>再组合成 datetime 对象，不走 strptime</h1><p>dt = datetime(2024, parse_chinese_month("三月"), 15)</p>
- 逻辑清晰，调试时一眼看出哪条映射没覆盖
- 零外部依赖，Docker、Windows、Alpine 全兼容
- 性能比
strptime()略快，毕竟只是字符串匹配+查表
如果必须用 strptime()，怎么最小化风险？
只在明确可控的单次解析中临时切 locale，并确保异常时也能恢复。
- 用
contextlib.suppress(locale.Error)吞掉 setlocale 失败，fallback 到映射表 - 永远不要在模块顶层或
__init__.py里调setlocale() - 避免用
%c、%x这类全 locale 依赖格式符，优先拆成%Y-%m-%d+ 手动替换
真正麻烦的不是写几行映射代码，而是有人坚持“strptime 就该能解析中文”，然后花三天查 CI 日志里的 locale 输出，最后发现只是忘了在 GitHub Actions 的 runner 上装 locales-all 包。
