.net core 3.1中oracle.manageddataaccess.core默认禁用tns解析，不读取tnsnames.ora；须改用easy connect（如data source=host:port/service_name）或完整description格式，且需注意大小写、空格、unicode=true、pooling=false及密码url编码等关键参数。
直接用 Data Source=tns别名 报错，大概率不是配置写错了，而是 TNS 解析根本没走你预期的路径——.NET Core 3.1 的 Oracle.ManagedDataAccess 默认不读取本地 tnsnames.ora 文件。
为什么 tns别名 在 .NET Core 3.1 里不生效
Oracle 官方驱动在托管模式下（即使用 Oracle.ManagedDataAccess.Core）默认禁用 TNS 名称解析，除非显式启用。它不会自动查找或加载 tnsnames.ora，哪怕你把它放在 %ORACLE_HOME%\network\admin 或项目根目录下也无效。
- 错误现象：
ORA-12154: TNS could not resolve the connect identifier - 根本原因：驱动没触发 TNS 解析逻辑，而是直接尝试把别名当主机名去连
- 兼容性影响：.NET Framework 下用
System.Data.OracleClient或 ODP.NET Unmanaged 时可能正常，但换到托管驱动就断掉 - 解决方案不是“配对tnsnames.ora”，而是绕过它——用完整连接描述符（Easy Connect 或 DESCRIPTION）
必须用完整连接字符串，不能只写 tns别名
把 Data Source=ORCL_WRITE 这种写法换成硬编码的连接描述符，格式要严格符合 Oracle 要求。推荐用 Easy Connect 格式，简洁且免解析依赖：
User Id=myuser;Password=mypass;Data Source=localhost:1521/ORCLPDB1
如果数据库启用了服务名（非 SID），或者需要指定协议/地址类型，就用完整 DESCRIPTION：
User Id=myuser;Password=mypass;Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCLPDB1)))
- 注意大小写：SERVICE_NAME 区分大小写，和数据库实际值必须完全一致
- 避免空格：括号内外不能有多余空格，否则解析失败
- 不要混用：别在同一个连接串里既写
localhost:1521/ORCLPDB1又加CONNECT_DATA块 - 测试建议：先用 SQL*Plus 或 Oracle SQL Developer 验证该串能否连通，再粘进代码
如果非要走 tnsnames.ora，得手动开启解析
不是不能用，但必须显式告诉驱动去哪找、怎么读。需要两个动作：
- 设置环境变量
tnsnames.ora路径：TNS_ADMIN=C:\myapp\config（Windows）或export TNS_ADMIN=/home/myapp/config（Linux） - 在连接字符串中加参数：
Connection Timeout=15;TNS_ADMIN=C:\myapp\config（部分版本支持，但不如第一种稳定） - 确保
tnsnames.ora文件里定义的别名不含特殊字符，且每条记录结尾有空行（某些旧版驱动会因格式问题静默失败） - 不推荐在容器或跨平台部署中依赖此方式——路径不可控，调试成本高
连接字符串里最容易被忽略的三个坑
即使格式正确，仍可能因隐含参数失败：
-
Unicode=True必须显式加上，否则中文字段可能乱码或报ORA-12704 -
Pooling=false在读写分离场景下是刚需，否则连接池可能复用错库连接（比如读操作拿了写库连上来的空闲连接） - 密码含特殊字符（如
@、;、=）必须 URL 编码，例如Password=pass@123→Password=pass%40123
这些细节不报错，但会在查询时悄悄出问题，比如查不到数据、插入截断、时间字段偏移——它们藏在连接建立之后，比连不上更难定位。
