Mac 用户在 Oracle 测试容器中插入带引号的数字字符串（如 '99.99000'）时触发 ORA-01722，本质是因系统区域设置导致 NLS_NUMERIC_CHARACTERS 不一致，引发隐式类型转换失败；根本解法是避免字符串传数值，统一使用无引号字面量或参数化 SQL。
mac 用户在 oracle 测试容器中插入带引号的数字字符串（如 `'99.99000'`）时触发 ora-01722，本质是因系统区域设置导致 `nls_numeric_characters` 不一致，引发隐式类型转换失败；根本解法是避免字符串传数值，统一使用无引号字面量或参数化 sql。
在 Java + Hibernate + Oracle 的测试环境中，ORA-01722: invalid number 是一个典型但易被误解的错误。它并非数据库建表或实体定义问题，而是隐式类型转换失控的结果——尤其在跨平台（macOS/Linux/Windows）协作时表现得尤为突出。
? 错误成因：NLS 设置差异放大了隐式转换风险
Oracle 在将字符串插入 NUMBER 或 DECIMAL 类型列（如 upper_bound 对应的 NUMBER(10,5)）时，会依据当前会话的 NLS_NUMERIC_CHARACTERS 参数解析小数点和千位分隔符。该参数格式为 'decimal_separator,group_separator'，默认值通常为 '.,'（英文环境），但在部分 macOS 系统（尤其非美区语言环境或未显式配置 NLS_LANG 时），JDBC 驱动可能继承系统 locale 并设置为 ',.' —— 此时 '99.99000' 中的 . 被视为千分位符而非小数点，导致转换失败：
-- 在 NLS_NUMERIC_CHARACTERS = ',.' 的会话中：
INSERT INTO policy_restriction_bound (...) VALUES ('1','1','2','99.99000','USD');
-- ❌ ORA-01722：Oracle 尝试把 '99.99000' 当作 "99千99000" 解析，非法而 Linux/Windows 机器常默认使用英文 locale，NLS_NUMERIC_CHARACTERS 保持 '.,'，因此相同 SQL 可通过——这解释了为何仅 macOS 用户复现该问题。
✅ 正确实践：杜绝隐式转换，从源头保障健壮性
✅ 方案 1：SQL 脚本中直接使用数值字面量（推荐用于测试数据）
移除所有数字字段的单引号，让 Oracle 直接识别为数值类型：
protected List<String> getInsertTestDataAfterMigrationCommands() {
return List.of(
"INSERT INTO policy_restriction_bound(id, policy_restriction_id, minimum_approves_count, upper_bound, currency) " +
"VALUES (1, 1, 2, 99.99000, 'USD')" // ← id, min_count, upper_bound 均无引号
);
}⚠️ 注意：
upper_bound是BigDecimal字段，对应 OracleNUMBER(p,s)，必须以数字形式（非字符串）写入；字符串'99.99000'强制触发不可靠的隐式转换。
✅ 方案 2：生产级首选 — 使用 JDBC 参数化查询（Hibernate/JPA 原生支持）
避免硬编码 SQL，交由框架处理类型绑定：
// 示例：在 Repository 或 Test 中使用 JPQL/Query
@Modifying
@Query("INSERT INTO PolicyRestrictionBoundEntity (id, policyRestriction, minimumApprovesCount, upperBound, currency) " +
"VALUES (:id, :policyRestriction, :minCount, :upperBound, :currency)")
void insertTestRecord(
@Param("id") Long id,
@Param("policyRestriction") PolicyRestrictionEntity policyRestriction,
@Param("minCount") Integer minCount,
@Param("upperBound") BigDecimal upperBound, // ← 自动映射为 NUMBER
@Param("currency") String currency
);Hibernate 会通过 JDBC PreparedStatement.setBigDecimal() 安全传递，完全绕过字符串解析逻辑。
✅ 方案 3：若必须用字符串 SQL，统一会话 NLS（仅限调试/兼容旧脚本）
在执行 DML 前显式设置会话参数（需确保权限）：
// 执行任意 SQL 前先运行： "ALTER SESSION SET NLS_NUMERIC_CHARACTERS = '.,'"; "ALTER SESSION SET NLS_TERRITORY = 'AMERICA'";
可通过 OracleContainer 的自定义初始化命令注入：
private static final OracleContainer DB_CONTAINER = new OracleContainer("gvenzl/oracle-xe:18.4.0-slim-faststart")
.withInitScript("init-nls.sql"); // 内容包含 ALTER SESSION 语句? 重要提醒：永远不要依赖隐式转换
- Oracle 官方文档明确建议：“Avoid implicit data type conversion in SQL statements”。
- 隐式转换不仅引发 ORA-01722，还可能导致索引失效、性能下降及难以复现的区域性 Bug。
-
BigDecimal字段在 Java 层已具备精确数值语义，将其转为字符串再塞进数据库，是典型的类型语义丢失。
✅ 总结：三步规避 ORA-01722
-
写 SQL 时：数字字面量不加引号（
99.99000✅，'99.99000'❌）； - 写 Java 时：优先使用参数化查询，让 Hibernate/JDBC 处理类型绑定；
-
配环境时：测试容器与生产库保持
NLS_TERRITORY一致（如AMERICA），但不作为主要解决方案。
遵循以上原则，即可彻底告别 macOS 特有的 ORA-01722，实现真正可移植、可预测的数据插入行为。
