修改 listener.ora 端口号只是第一步，必须确认监听实际加载该文件、同步修改 ADDRESS 中 PORT 和 IPC KEY、执行 lsnrctl stop/start 重载配置，并更新 JDBC/tnsnames.ora 等客户端配置，否则连接仍会失败。
修改 listener.ora 里的端口号就完事了？别急，先确认监听是否真在用这个文件
oracle 监听器启动时默认读取 $oracle_home/network/admin/listener.ora，但实际生效的可能是它，也可能是动态注册后自动创建的内存配置。直接改完文件不重启监听，端口不会变。
实操建议：
- 先运行
lsnrctl status，看输出里 “Listening Endpoints Summary...” 那行，确认当前监听的地址和端口，这是真实状态 - 再执行
lsnrctl show config，它会告诉你当前加载的是哪个listener.ora文件路径（注意：有些环境可能显示 “No listener.ora file found”，说明监听是纯动态启动的） - 如果
show config显示没找到文件，那得先建一个标准listener.ora，否则改了也没人读
listener.ora 中必须改哪几处？只动 PORT 不够
常见错误是只改了 (PORT = 1521) 这一处，结果客户端连不上——因为 Oracle 的服务名注册、本地命名解析、甚至 JDBC URL 都可能隐式依赖端口一致性。
需要同步检查并修改以下三处（以改成 1522 为例）：
-
(ADDRESS = (PROTOCOL = TCP)(HOST = your-hostname)(PORT = 1521))→ 把1521改成1522 -
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))这行可删或保留，IPC 不影响网络端口，但 KEY 名带数字容易让人误判，建议改成EXTPROC1522保持语义一致 - 如果有
ADR_BASE_LISTENER或日志路径含端口号的自定义配置，也顺手更新，避免后续查日志时混淆
改完记得保存，别用记事本另存为导致编码乱码（Linux 下推荐 vi 或 sed -i）
改完不 reload 就等于白改：lsnrctl reload 和 stop/start 的区别
reload 是热加载，它会重新读 listener.ora，重载监听地址，同时保持已有连接不断开；而 stop/start 会中断所有正在传输的连接，生产环境慎用。
但要注意：reload 不会清理旧的注册服务——比如之前用 1521 注册过的实例，可能还挂在老端口上。所以更稳妥的做法是：
- 先
lsnrctl stop - 再
lsnrctl start（确保从新配置冷启动） - 最后用
lsnrctl services检查输出里是否只出现新端口（如1522），且STATUS是READY
如果看到新旧端口同时存在，大概率是多个 listener.ora 被误加载，或者有另一个监听进程在后台跑着
JDBC 和 tnsnames.ora 也要跟着动，否则客户端连的还是老端口
很多人改完监听器就以为搞定了，结果应用一连就报 IO Error: The Network Adapter could not establish the connection。这是因为客户端根本没告诉它去连哪个端口。
必须同步检查：
- JDBC URL 中的端口：如
jdbc:oracle:thin:@host:1521:orcl→ 改成@host:1522:orcl -
$ORACLE_HOME/network/admin/tnsnames.ora里对应的服务名定义，里面的(PORT = 1521)同样要改 - 如果用了 Oracle Wallet 或连接池（如 HikariCP、Druid），确认连接池配置里没硬编码端口
改完别忘了测试：用 sqlplus /@your_service_name 本地连一次，再用 telnet host 1522（或 nc -zv host 1522）验证端口通不通
真正容易被忽略的是：RAC 环境下每个节点都要单独改各自的 listener.ora，而且 SCAN 和 VIP 的监听端口是另一套机制，不能只动单机配置。还有，防火墙策略、云平台安全组、SELinux（Linux）这些外部拦截点，往往比配置本身更早卡住连接。
