Kratos启动报“address already in use”直接原因是默认监听0.0.0.0:9000被其他进程占用，需用netstat -ano | findstr :9000（Windows）或lsof -i :9000（Linux/macOS）查PID及进程名定位真凶。
kratos run 启动报错 “address already in use” 怎么定位
直接原因是 kratos run 默认监听 0.0.0.0:9000，而该端口已被其他进程（比如另一个 kratos 实例、Node.js 服务、旧容器或调试器）占用。不要先改代码，先确认谁在抢这个端口。
Windows 下执行：netstat -ano | findstr :9000
Linux/macOS 下执行：lsof -i :9000 或 netstat -tulnp | grep :9000
输出中会带出 PID 和进程名。若看到多个 kratos 或 go 进程，大概率是前一次没 kill 干净的残留服务；若看到 java 或 node，说明是其他开发服务占用了。
- 别直接
kill -9所有 go 进程——可能误杀正在跑的调试任务 - kratos 默认端口不是固定写死在代码里的，而是从配置加载，所以改配置比改源码更安全
- 注意区分：
cmd/main.go中的app.Run()不负责监听端口，真正绑定的是 HTTP server 初始化那块（通常在internal/server/http.go）
kratos 服务端口在哪配？改哪里才生效
kratos 的端口由 HTTP server 的配置驱动，不是靠命令行参数硬编码。关键路径是：configs/config.yaml（或 .env + config.yml 分离场景）里的 server.http.addr 字段。
例如：
server:
http:
addr: 0.0.0.0:9001 # ← 改这里
timeout: 1h改完后必须重启 kratos run，且确保没缓存旧配置（尤其用 kratos new 生成的项目，有时 config.yaml 被 gitignore 忽略了，实际读的是本地副本）。
- 如果用
kratos run -c config_dev.yaml指定了配置文件，就去改那个文件，不是默认的config.yaml - 某些模板项目把端口藏在
internal/server/http.go的http.NewServer调用里硬编码了，这种属于反模式，优先提 PR 改回配置驱动 - Go 程序启动时若读不到配置，kratos 会 fallback 到默认值（如
:9000），所以空配置 ≠ 安全
Docker 启动 kratos 镜像也冲突？检查宿主机和容器双层端口
用 docker run -p 9000:9000 启动 kratos 容器失败，错误类似：driver failed programming external connectivity on endpoint: Bind for 0.0.0.0:9000: unexpected error (Failure)
这表示宿主机的 9000 端口被占，**不是容器内端口冲突**。Docker 只管宿主机端口映射，容器内部监听哪个端口（比如 :8000）是另一回事。
- 先运行
lsof -i :9000确认宿主机端口占用，再决定是停进程还是换映射端口 - 改映射最简单：
docker run -p 9001:9000 kratos-app（把宿主机9001映射到容器内9000） - 如果容器内服务本身也监听
:9000，而你又想让它对外暴露:9001，就得同步改容器内的配置（即上一节说的config.yaml），否则流量进不来 - 用
docker ps --format "table {{.Names}}\t{{.Ports}}"可快速看哪些容器正在占哪些宿主机端口
为什么改了端口还是冲突？留意动态端口和 TIME_WAIT
有时候改了 9000 → 9001，但 9001 仍报冲突，常见于高频启停开发环境。原因不是别人占了，而是你自己刚关掉的服务还没彻底释放端口。
TCP 连接关闭后会进入 TIME_WAIT 状态，默认持续 2×MSL（通常 60 秒）。期间同一四元组（IP+端口）无法重用。如果你的 kratos 服务频繁崩溃重启，很容易卡在这里。
- 临时绕过：
sudo sysctl -w net.ipv4.tcp_tw_reuse=1（Linux），允许 TIME_WAIT 端口被复用 - 更稳妥的做法：让 kratos HTTP server 启动时加
SO_REUSEADDR标志（kratos 默认已启用，但某些自定义封装可能漏掉） - 别依赖
localhost:9000做健康检查脚本——它可能连得上，但实际服务还没完成初始化，造成误判“端口空闲”
Kratos 的端口问题核心不在框架本身多复杂，而在于它把配置、启动、容器化三层解耦开了。最容易漏掉的是：你以为改了配置，其实程序读的是另一个路径；你以为停了容器，其实宿主机端口还挂在 TIME_WAIT 里。动手前，先 lsof -i 或 netstat 看一眼真实状态。
