TO_DATE未指定格式模型时，Oracle会依赖会话级NLS_DATE_FORMAT参数解析字符串，导致跨环境行为不一致甚至ORA-01843错误；必须显式指定格式模型并配合NLS_DATE_LANGUAGE确保语言一致性。
TO_DATE没写格式模型时，Oracle会偷偷用NLS_DATE_FORMAT
你写的 TO_DATE('2023-07-28') 看似没问题，但 Oracle 实际上会去查当前会话的 NLS_DATE_FORMAT 值，拿它当默认格式模型来解析。如果会话里是 'DD-MON-RR'，那这个字符串根本匹配不上，直接报 ORA-01843: 无效的月份——因为 '07' 被当成月份缩写，而 Oracle 在该格式下只认 'JUL' 这类英文缩写。
常见错误现象：
- 同一句 SQL，在 SQL*Plus 里能跑，在 JDBC 应用里报错
- 开发环境正常，测试环境执行失败，查出来两边
NLS_DATE_FORMAT不一样 - 用中文月份（如
'28-七月-23'）却配了AMERICAN_AMERICA的NLS_LANG，结果月份解析失败
根本原因不是函数本身有问题，而是你没显式指定格式模型，把控制权交给了 NLS 参数。而 NLS_DATE_FORMAT 是会话级的，可能被应用连接池、中间件、甚至前一条 ALTER SESSION 语句悄悄改掉。
不同NLS_LANG设置对TO_DATE行为的影响
NLS_LANG 决定了三件事：消息语言、日期/月份显示语言、数字/货币格式。其中第二项直接影响 TO_DATE 对 MON、DAY 这类元素的识别。
比如：
-
NLS_LANG=AMERICAN_AMERICA.AL32UTF8→MON只认'JAN','FEB'等英文缩写 -
NLS_LANG=SIMPLIFIED CHINESE_CHINA.AL32UTF8→MON才可能识别'一月'、'二月'（但前提是数据库版本支持且字符集兼容）
注意：NLS_LANG 不是数据库参数，它是客户端环境变量。服务端不会“继承”它，而是由客户端发给服务端协商使用。所以 JDBC 连接串里没设 oracle.jdbc.mapDateToTimestamp=false 或没传 NLS_LANG，服务端就按默认值处理，很可能跟你的本地 SQL*Plus 不一致。
为什么ALTER SESSION SET NLS_DATE_FORMAT不推荐作为修复手段
临时改会话参数看似简单，但副作用明显：
- 影响整个会话后续所有隐式日期转换，包括视图、触发器、其他存储过程里的
TO_DATE调用 - 如果存储过程中有异常处理块，里面又调用了
TO_DATE，可能因格式突变导致二次报错 - 多线程环境下，一个连接被连接池复用，
ALTER SESSION的效果可能污染其他业务逻辑
更麻烦的是，有些框架（如 MyBatis）会在执行 SQL 前自动加 ALTER SESSION 设置时区或语言，你写的那条 ALTER SESSION SET NLS_DATE_FORMAT 可能被覆盖或顺序错乱。
真正安全的做法：永远显式写格式模型
别依赖任何 NLS 设置，把格式写死在代码里：
SELECT TO_DATE('2023-07-28', 'YYYY-MM-DD') FROM DUAL;
SELECT TO_DATE('28-JUL-2023', 'DD-MON-YYYY', 'NLS_DATE_LANGUAGE=AMERICAN') FROM DUAL;
关键点：
- 字符串和格式模型必须严格位数、顺序、语言一致；
'YYYY-MM-DD'不能写成'YY-MM-DD'，否则 2023 年会被截成 23 - 涉及
MON、DAY时，加第三参数NLS_DATE_LANGUAGE显式锁定语言，避免被NLS_LANG搞乱 - 批量脚本或迁移任务中，优先用
TO_DATE+ 明确格式，而不是靠改会话参数“统一解决”
最常被忽略的一点：即使你确认当前会话的 NLS_DATE_FORMAT 是 'YYYY-MM-DD'，也不能保证下一次执行时它还是——尤其在连接池、长事务、或 DBA 手动干预后。显式格式模型是唯一可控的锚点。
