ORA-12541错误根本原因是监听器未运行、绑定地址错误（如localhost）或网络不通；须先用tnsping验证TNS解析与连通性，再查监听进程、修改listener.ora中HOST为真实IP并lsnrctl reload，最后确认防火墙放行1521端口。
ORA-12541 不是你的 C# 代码写错了，而是连接根本没发到 Oracle 实例上——监听器（listener）没起来、配错了，或者网络压根不通。
tnsping 能通才是第一步
别急着改 connectionString 或重装驱动。先确认最底层的网络和监听可达性：
-
tnsping ORCL（把ORCL换成你连接串里的Data Source值）必须返回OK且有毫秒数，否则后续全是空谈 - 如果报
TNS-03505: Failed to resolve name，说明tnsnames.ora文件缺失或路径不对；TNS_ADMIN环境变量要指向含该文件的目录（如C:\oracle\network\admin） - Windows 上检查服务列表里是否有
OracleOraDb19cHome1TNSListener这类名称的服务，并确保状态为“正在运行”
连接串里 Data Source 别硬写 TNSNAMES 别名
很多 .NET Core 应用直接抄了 SQL*Plus 的写法，把 Data Source=ORCL 当成万能钥匙——但 ORCL 得在 tnsnames.ora 里真实存在，且内容正确。更稳妥的做法是直连：
- 用 Easy Connect 格式：
Data Source=localhost:1521/ORCL（注意是斜杠/，不是冒号:） - 若实例用的是非默认端口（比如 1522），必须显式写出：
Data Source=localhost:1522/ORCL - 服务名（
ORCL）和数据库实际的SERVICE_NAME必须一致，大小写敏感；查它用：SELECT value FROM v$parameter WHERE name = 'service_names';
Oracle.ManagedDataAccess.Core 不会帮你启动监听器
托管驱动（Oracle.ManagedDataAccess.Core）省去了客户端安装，但它不负责监听器生命周期管理——这点常被误判。常见混淆点：
- 你在开发机上用 Visual Studio 跑通了，不代表服务器上也能通；服务器上得单独确认监听服务是否启动、端口是否被防火墙拦截
- Docker 环境下，
localhost指容器自身，.NET Core 应用连 Oracle 容器得用宿主机 IP 或 Docker 网络别名，不能写localhost:1521 - Linux 服务器上监听器默认只绑定
127.0.0.1，远程连接会失败；需修改listener.ora中的HOST为0.0.0.0或具体网卡 IP
ORA-12541 和 ORA-12514 容易搞混，但排查路径完全不同
ORA-12541: TNS:no listener 是监听进程压根没响应，属于网络/服务层问题；而 ORA-12514: TNS:listener does not currently know of service requested 是监听起来了，但数据库实例没向它注册服务。两者错误日志位置也不同：
-
ORA-12541查$ORACLE_HOME/network/log/listener.log通常为空或只有启动记录 -
ORA-12514同一文件里会有类似TNS-12514: Service "ORCL" has not been registered的明确提示 - 验证注册：在数据库内执行
SELECT * FROM V$LISTENER_NETWORK;和SELECT SERVICE_NAME FROM V$ACTIVE_SERVICES;
真正卡住人的，往往不是驱动怎么选、代码怎么写，而是监听器在哪个 IP 上监听、服务名拼对了没有、防火墙放行了没——这些基础设施细节一旦出错，OracleConnection.Open() 就永远等不到响应。
