端口8888被占用时，应定位并终止真正监听该端口的进程，而非直接换端口或重启电脑；Linux/macOS用lsof -i :8888查PID和进程名，Windows用netstat -ano | findstr :8888配合tasklist确认进程，再安全终止。
直接结论：端口 8888 被占用，不是必须“换端口”或“重启电脑”，而是要定位并终止真正监听该端口的进程；盲目用 --port=8889 只是掩盖问题，尤其在远程、Docker 或多用户环境下可能引发连接失败或 token 无效。
怎么查谁在用 8888 端口（Linux/macOS）
优先用 lsof，它能直接关联到进程名、用户和命令，比 netstat 或 ss 更准：
- 运行
lsof -i :8888—— 如果返回类似python3 12345 alice 3u IPv4 ... *:8888 (LISTEN)，说明 PID 12345 的 Python 进程占着 - 若无输出但确信被占，可能是
launchd（macOS）或systemd托管服务，试sudo lsof -i :8888 - 避免只用
ss -tuln | grep 8888：它不显示进程名，容易误杀无关服务
怎么查谁在用 8888 端口（Windows）
Windows 下 netstat 是基础，但必须配合管理员权限和精确过滤：
- 以管理员身份打开 CMD 或 PowerShell，运行：
netstat -ano | findstr :8888（注意冒号不能漏） - 输出最后一列是 PID，比如
TCP 0.0.0.0:8888 0.0.0.0:0 LISTENING 6852→ PID 是 6852 - 再查进程名：
tasklist | findstr "6852"，确认是不是python.exe、jupyter-notebook.exe或其他（如 Docker Desktop、VS Code 后台服务） - 别信“没结果就代表没占用”——Hyper-V 或 WSL2 有时会静默占用，需额外检查
netsh interface portproxy show v4tov4
怎么安全终止占用进程（跨平台通用原则）
别一上来就 taskkill /F 或 kill -9，先判断是否是你自己的 Jupyter 实例：
- 如果是你自己上次没关干净的
jupyter notebook，用jupyter notebook list查活跃服务，再用jupyter notebook stop 8888安全退出 - 如果确认是无关进程（比如另一个用户启动的、Docker 容器、恶意软件），再强制终止：
Linux/macOS：kill -15 12345（优雅终止），不行再kill -9 12345
Windows：taskkill /PID 6852 /F - 特别注意 PyCharm 内置 Jupyter：它常启独立
python.exe，任务管理器里按“映像名称”排序找python.exe更快
为什么换端口有时也不行（常见盲区）
当你执行 jupyter notebook --port=8899 却仍报错“Permission denied”或页面空白，往往不是端口本身问题：
- 远程场景：SSH 端口转发只绑定了
localhost:8888，你换到 8899 后没同步改ssh -L参数，本地根本连不到 - Docker 场景：容器内用了
--port=8899，但-p映射还是8888:8888，外部请求进不来 - 浏览器缓存：Jupyter 7.13+ 版本对 8888/8889 有 manifest 缓存 bug，换端口后仍加载旧缓存，导致空白页 —— 此时需清空浏览器所有站点数据，不只是缓存
- Windows Hyper-V：出现连续多个端口（8889、8890…）都被拒，大概率是 WinNAT 服务异常，需管理员运行：
net stop winnat && net start winnat
最易被忽略的一点：Jupyter 启动后终端显示 http://localhost:8889/...，但你复制链接时没注意端口号已变，还往 8888 粘，自然打不开。看清楚终端第一行输出的 URL，比任何排查都快。
