ORA-12154 错误通常并非数据库本身不可达，而是 .NET Core 进程未能正确加载或读取 tnsnames.ora 配置文件——进程无法定位 TNS 名称解析路径，从而触发该错误。

先确认你使用的 Oracle 驱动类型

这一判断决定了你是否有必要折腾 tnsnames.ora：

• 如果 NuGet 包引用的是 Oracle.ManagedDataAccess（.NET Core 推荐），默认情况下它不会读取 tnsnames.ora，仅依赖连接字符串中的完整地址；修改文件无效。
• 如果引用的是 Oracle.DataAccess（旧版非托管驱动），则依赖本地 Oracle Client 和 tnsnames.ora，但必须确保加载的 oci.dll 来自你配置的路径（可通过 Process Explorer 查看进程加载的 dll 路径进行验证）。

正确设置 TNS_ADMIN 环境变量并验证其生效

即便你使用了 Oracle.ManagedDataAccess，某些版本或特定场景下仍会尝试读取（尤其配合 sqlnet.ora 时），因此必须确保该变量被 .NET Core 进程实际继承：

• 在代码启动前显式设置：Environment.SetEnvironmentVariable("TNS_ADMIN", @"C:\oracle\instantclient_21_12\NETWORK\ADMIN");
• 不要仅依赖 CMD 中的 set TNS_ADMIN=xxx —— IDE 启动、IIS 托管、Windows 服务均不会自动继承该变量。
• 运行时检查：Environment.GetEnvironmentVariable("TNS_ADMIN") 必须返回非空路径，否则整个目录被跳过。
• IIS 应用池需勾选“加载用户配置文件”，否则系统环境变量不可见。

确保 tnsnames.ora 文件格式完全合规

即使路径正确，一个不可见字符也会导致解析失败，报错仍为 ORA-12154，且不提示具体错误行：

• 使用 VS Code 或 Notepad++ 打开，开启“显示不可见字符”，确认别名行首无空格、无制表符：ORCL = 是错误的，正确写法应为 ORCL=。
• 保存为UTF-8 无 BOM —— Windows 记事本默认 ANSI 或带 BOM，会导致整文件解析失败。
• 等号前后、括号内外不能有多余空格；注释必须独占一行且以 # 开头（不是 !）；右括号必须换行闭合。
• 大小写敏感：tnsnames.ora 中写的是 ORCL=，则连接字符串中就不能写 orcl。

绕过 tnsnames.ora 的简易直连方案

开发阶段优先使用直连格式，彻底排除名称解析链路干扰：

• 连接字符串写成：Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.10)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl)));User Id=scott;Password=tiger;
• 注意：SERVICE_NAME 值区分大小写（如 12c+ 多租户下常为小写 orclpdb1），不要误写成 SID。
• 若必须使用别名，确保同目录下存在 sqlnet.ora，且包含 names.directory_path = (tnsnames)，否则别名直接失效。

真正容易被忽略的关键点是：tnsping 成功 ≠ 应用能连接 —— tnsping 使用的是你命令行环境下的 Oracle Client，而 .NET Core 进程可能加载了另一个 Instant Client 或完全未读取 TNS_ADMIN。验证必须落实到进程内部，而非外部工具输出。