必须显式设置ClientCharacterSet，因Oracle.ManagedDataAccess默认按US7ASCII解析导致中文乱码；需先查数据库字符集（如ZHS16GBK或AL32UTF8），再在连接字符串中对应指定ClientCharacterSet值。
连接字符串里必须显式写 ClientCharacterSet
中文乱码不是网络或编码转换问题，是驱动默认按 US7ASCII 解析字符串导致的。Oracle.ManagedDataAccess 不读 NLS_LANG 环境变量，也不继承系统区域设置。
- 先查数据库实际字符集：
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET'; - 若返回
ZHS16GBK，连接字符串必须包含ClientCharacterSet=ZHS16GBK - 若返回
AL32UTF8，就得写ClientCharacterSet=AL32UTF8（注意不是UTF8或UTF-8） -
Unicode=True在托管驱动里已废弃，加了也没用，还可能触发兼容模式
ReadOnly=True 在连接字符串里完全无效
Oracle 没有类似 SQL Server 的 ApplicationIntent=ReadOnly 机制，ReadOnly=True 参数会被 Oracle.ManagedDataAccess 忽略——写操作照样执行，连接也不会自动路由到备库。
- 读写分离必须靠两个独立连接字符串：
Data Source=ORCL_PRIM（主库）和Data Source=ORCL_STBY（只读库） - 读库连接串务必加
Pooling=false，否则连接池会混用主/备库连接，引发连接池污染 - 不要复用同一个
OracleConnectionStringBuilder实例，仅改DataSource属性——这会导致内部连接池键冲突 - EF Core 场景下，得定义两个
DbContext类型，分别绑定不同连接串
TraceFile 日志必须在 config 文件里配，代码赋值无效
OracleConfiguration.TraceFile 是只读属性，运行时设了也不生效。日志开关只认 app.config 或 web.config 里的配置节。
- 在
<oracle.manageddataaccess.client>下加<tracing traceFileName="C:\temp\odpnet.trc" traceLevel="7" /> -
traceFileName强烈建议用绝对路径，相对路径容易因工作目录变化写到奇怪位置（比如 IIS 下落到C:WindowsSysWOW64） - 检查进程账户对目标目录是否有写权限，路径中含中文或空格也可能导致静默失败
- 日志里重点看带
[pid:xxx,tid:xxx]前缀的行，出错前几行常有底层 Socket 或 TNS 解析失败提示
Managed 驱动不依赖 Oracle Client，但配置残留会坏事
Oracle.ManagedDataAccess.dll 是纯托管实现，自带协议栈，不需要安装 Oracle Client。但旧项目常因残留配置强行加载本地组件。
- 确认项目中已彻底移除
Oracle.DataAccess.dll引用和using Oracle.DataAccess.Client; -
app.config或web.config中的<dbProviderFactories>节点，必须删掉或注释掉所有Oracle.DataAccess.Client条目 - 连接字符串支持 EZConnect 格式（如
//host:1521/PDB1），若用tnsnames.ora，需通过TNS_ADMIN环境变量指定文件所在目录 - EF6 场景下，
<entityFramework>节点里defaultConnectionFactory和provider的类型名必须匹配 NuGet 安装的Oracle.ManagedDataAccess.EntityFramework版本
ClientCharacterSet 配错，哪怕连得上、查得出，中文字段也会无声变问号——这种问题往往要等业务数据导出才暴露。 
