根本原因是其他进程（如残留uvicorn、python进程或docker服务）占用目标端口；需用netstat/lsof查pid，再kill或改端口，避免仅靠ctrl+c或换端口治标不治本。
FastAPI 启动失败报 Address already in use，根本原因不是 FastAPI 本身占着端口不放，而是你本地已有其他进程（包括上一次没关干净的 uvicorn、python 进程，或别的服务）正在监听同一个端口。
为什么 Ctrl+C 没真正关掉服务？
在终端里按 Ctrl+C 理论上会触发 KeyboardInterrupt 让 uvicorn 正常退出，但实际中容易失效：
- PyCharm 直接点红色停止按钮，有时只杀掉了前台 shell，后台 Python 子进程仍存活
- Windows 下终端被强制关闭（叉掉窗口），
python.exe进程不会收到退出信号，直接残留 - 代码里用了
BackgroundTasks或子线程未设为daemon=True，主进程退出后它们还在跑，持续占用端口 - 你在 Docker Compose 中启了服务，又在宿主机手动
uvicorn main:app，两个都盯8000
怎么快速确认是哪个进程占了 8000？
别猜，直接查。不同系统命令略有差异，但目标一致：拿到 PID，再 kill。
Windows：netstat -ano | findstr :8000
看到类似 TCP 127.0.0.1:8000 0.0.0.0:0 LISTENING 12345，然后tasklist | findstr 12345 看是不是 python.exe；确认后执行taskkill /pid 12345 /f
macOS / Linux：lsof -i :8000 或 ss -tuln | grep :8000
输出里带 PID 和 COMMAND，比如 uvicorn 或 python3，接着kill -9 12345
启动时如何避免反复踩坑？
与其每次出问题再查，不如把习惯调对：
- 开发时固定用
--port 8001启动，避开默认8000，减少冲突概率 - PyCharm 运行配置里勾选 “Allow parallel run”，防止误点两次重复启动
- 写个一键清理脚本（尤其 Windows 用户）：
for /f "tokens=5" %a in ('netstat -ano ^| findstr :8000') do @taskkill /f /pid %a 2>nul - Docker Compose 调试时，删掉
ports: ["5678:5678"]这类映射——它和 PyCharm 的调试器抢端口，不是必须的
端口冲突本身不难解，难点在于残留进程藏得深、跨环境（宿主机 + 容器）、且错误信息不指明“是谁占的”。查 PID 是最稳的路径，别跳过这步直接换端口，否则下次还是撞上。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
