应先确认tnslsnr进程是否真实运行，再用netstat检查1521端口是否listening且绑定0.0.0.0或真实ip而非127.0.0.1，接着核对hosts/hostname配置一致性，最后排查sshd或杀软等隐形占坑者。
直接看监听进程和端口状态，别只信报错提示
Oracle 报“端口被占用”，不等于真有别的程序在抢 1521。更常见的是监听器自己没起来、配置冲突、或系统层面的地址绑定问题。先确认 tnslsnr 进程是否真在跑，再查端口实际监听状态。
- Linux/macOS：运行
ps -ef | grep tnslsnr，看到类似/u01/app/oracle/product/19c/dbhome_1/bin/tnslsnr的行才算真启动了 - Windows：打开任务管理器 → “详细信息”页签 → 搜索
tnslsnr.exe，必须存在且状态为“正在运行” - 别只信
lsnrctl status输出——它可能因环境变量错误返回假成功；进程不存在，status就是无效反馈
用 netstat 查端口真实监听情况，重点看绑定 IP
netstat 能告诉你端口是不是真在 LISTENING，以及监听在哪张网卡上。绑定 127.0.0.1 和绑定 0.0.0.0 或具体 IP，对远程连接效果完全不同。
- Linux：执行
netstat -tuln | grep :1521（把 1521 换成你实际监听的端口），输出中应含LISTEN，且Local Address列是*:1521或192.168.x.x:1521，不是127.0.0.1:1521 - Windows：执行
netstat -ano | findstr :1521，确认状态为LISTENING，并记下 PID，再用tasklist /fi "pid eq XXXX"查对应进程名是否为tnslsnr.exe - 如果查不到 LISTENING，说明监听根本没生效；如果只绑定到
127.0.0.1，Navicat 或远程客户端必然超时
警惕 hosts 文件和 hostname 配置引发的“伪占用”
某些情况下 netstat 显示端口空闲，lsnrctl start 却坚持报“端口被占用”。这往往是 Oracle 解析自身主机名失败，导致监听器启动逻辑误判。
- 检查
/etc/hosts（Linux/macOS）或C:\Windows\System32\drivers\etc\hosts（Windows），确认数据库服务器 hostname 对应的 IP 是本机真实网卡 IP，不是旧地址或127.0.0.1 - Linux 下运行
hostname，输出必须与/etc/hosts中该 IP 后面的 hostname 完全一致；否则netca或lsnrctl会反复报端口冲突 - Windows 用户注意：
ORACLE_HOSTNAME环境变量值也必须和系统 hostname 及 hosts 文件匹配，否则监听器无法完成地址绑定
排除 sshd、杀软等“隐形占坑者”
真正被其他进程占了端口的情况虽少，但一旦发生，netstat 一定能抓到。尤其要注意那些默认不显眼、却可能被手动改过配置的服务。
- Linux 下执行
netstat -tulnp | grep :1521，看 PID 对应进程名。曾发现sshd被误配了ListenAddress绑定到 1521 —— 这种情况netstat显示4078/sshd，不是 Oracle - Windows 下杀毒软件（如 360、腾讯电脑管家）或 Windows Defender 防火墙可能拦截
tnslsnr.exe绑定端口，表现为监听器启动后立即退出，日志里无明确错误 - 临时关闭防火墙或杀软，再试
lsnrctl start；若成功，说明是安全策略干扰，需为tnslsnr.exe添加例外规则
