先运行lsof -i :8888（Linux/macOS）或netstat -ano | findstr :8888（Windows）查PID，再结合jupyter notebook list或tasklist确认是否为残留Jupyter实例，避免盲目换端口。
怎么快速确认是哪个进程占了8888端口
别急着换端口或重启电脑。先确认是不是你自己启动的另一个 Jupyter 实例在后台跑着——比如上次没关掉的 jupyter notebook，或者 VS Code 自动拉起的内核服务。
在 Linux/macOS 上直接运行：lsof -i :8888
输出里会显示 COMMAND、PID、USER 和 NAME，一眼就能看出是不是你自己的 python3 进程。
Windows 用户用：netstat -ano | findstr :8888
拿到 PID 后再查进程名：tasklist | findstr "12345"（把 12345 换成你看到的 PID）
- 如果 PID 对应的是
python.exe或jupyter-notebook，大概率是你自己的残留实例 - 如果显示
System或svchost.exe（Windows），可能是 Hyper-V 的 WINNAT 服务在拦截，不是真被“占用”，而是权限被拒 - 如果
lsof或netstat返回空，但错误依旧存在，说明端口可能被launchd（macOS）或systemd（Linux 容器）托管的服务悄悄监听，得查更底层日志
杀进程前先判断要不要杀
盲目 kill -9 或 taskkill /f /pid 可能中断正在跑的训练任务或数据处理脚本。动手前快速扫一眼：
- 用
jupyter notebook list查当前合法运行的 Notebook 实例——它只显示通过jupyter正常启动的服务，PID 会列出来 - 如果
lsof显示的 PID 不在jupyter notebook list输出里，基本可判定是僵尸进程或非 Jupyter 进程（比如某个 Flask 服务误配了 8888） - VS Code 用户注意：它的 Jupyter 扩展默认也用 8888，且不注册到
jupyter notebook list，此时看COMMAND是Code Helper还是python更可靠 - Mac 上遇到
lsof查不到但端口仍被占，试试sudo lsof -i :8888——有些系统服务需要 root 权限才能显形
Windows 下 Permission denied 连续报错怎么办
如果你看到一连串 Permission to listen on port XXXX denied，不是端口被占，而是 Hyper-V 的网络地址转换服务（WINNAT）锁死了低端口范围。这时候换端口没用，因为 8888–8999 都可能被拦。
临时解法（需管理员权限）：net stop winnatnet start winnat
- 执行后不用重启，Jupyter 就能立刻绑定 8888
- 这不是永久关闭，只是重置 NAT 表；不影响 Docker 或 WSL2 网络功能
- 如果经常触发，说明 WINNAT 内部状态异常，建议检查是否有多个 WSL2 发行版同时启动，或 Docker Desktop 和 WSL2 冲突
为什么换端口有时反而更麻烦
用 jupyter notebook --port=8889 能绕过问题，但容易掩盖真实冲突。比如：
- 你在 PyCharm 里配置了远程 kernel，它硬编码连 8888，换端口后 kernel 连不上
- 团队共享的 notebook 链接写死
localhost:8888，换端口就得改所有文档和脚本 - Docker 容器映射
-p 8888:8888，宿主机端口一换，容器外就访问不了 - JupyterLab 插件（如 jupyterlab-git）可能依赖默认端口做内部通信，换端口后部分功能失灵
真正省事的做法，是定位并清理源头——哪怕多花两分钟查 PID，也比以后反复调试路径、代理、CORS 和跨域问题强。
