Revel框架启动失败90%是端口占用或监听地址配置错误；需用lsof/netstat查PID并终止冲突进程，且必须检查0.0.0.0:9000及IPv6等所有绑定方式，不能仅查127.0.0.1。
Revel框架安装后打不开，90%的情况不是安装失败，而是服务根本没起来——最常见原因是端口被占、监听地址不对、或启动命令没走对流程。先别重装，按下面几步直接定位。
revel run 启动后立即报 “address already in use” 怎么快速确认真凶
这个错误来自操作系统拒绝绑定，不是 Revel 自己抛的。关键要查清楚谁在用那个端口，而不是换端口了事。
- Linux/macOS：运行
sudo lsof -iTCP:9000 -sTCP:LISTEN，看输出里的PID和进程名；若没结果，试试sudo netstat -tulnp | grep :9000 - Windows：运行
netstat -ano | findstr :9000得到PID，再用tasklist | findstr <pid></pid>查进程；若为空，换 PowerShell 执行Get-NetTCPConnection -LocalPort 9000 | Get-Process - 特别注意：Revel 默认监听
0.0.0.0:9000，哪怕你只查127.0.0.1:9000也漏掉真凶；[::]:9000（IPv6）或192.168.x.x:9000同样会冲突
能启动但 localhost 打不开，是不是 -addr 参数没生效
-addr 只控制 IP，不控制端口；且 Revel 的参数解析有隐式优先级，单独写 -addr 不会覆盖默认端口。
- 错误写法：
revel run myapp -addr 127.0.0.1→ 仍用 9000 端口，但只绑本地回环，外部连不上 - 正确写法：
revel run myapp -p 8080 -addr 0.0.0.0（开发调试推荐）或-addr 127.0.0.1（仅本机访问） - 容器/WSL2 场景必须用
0.0.0.0：否则即使端口映射成功，请求也进不到 Revel 进程里 - Windows 防火墙可能拦截：WSL2 中跑 Revel，主机访问时得手动放行对应端口
终端显示 “Watching for changes” 却始终无法访问任何路径
这说明 Revel 进程起来了，但路由压根没加载，或被拦截器提前截断了。
- 检查启动日志有没有
Loaded X routes from conf/routes；没有就代表conf/routes文件没被读取 - 确认
conf/routes是小写文件名、UTF-8 无 BOM、首行非空、放在项目根目录conf/下（不是conf/dev/） - 临时注释掉
app/init.go中所有revel.BEFORE_ROUTER类型的拦截器，看能否恢复 404 页面——这是判断是否被拦截的最快方式 - 用
curl -v http://localhost:9000/nonexistent看响应头：返回 200 或 500 而不是 404，基本可断定路由没走通
页面打开但模板空白、CSS 404、JS 不执行
这不是 Revel 启动问题，而是静态资源路径或布局模板链路断了，日志里通常完全没提示。
- 手动访问
http://localhost:9000/css/app.css，返回 200 且内容可读才算通；否则检查public/css/app.css是否存在、路径是否拼错 -
app/views/layout.html里引用的/css/app.css必须和public/下实际路径严格一致；Revel 不做路径映射，错一个字符就 404 - 自定义 404 页面必须放
app/views/errors/404.html，Revel 不会自动建errors/目录，手误放错位置等于没写 - dev 模式下
results.error.404配置完全无效——这是硬限制，别在 dev 下调 404 模板
真正卡住的地方往往不在代码里，而在配置加载顺序、文件系统事件通知、或 HTTP 请求生命周期的某个隐式环节。比如热重载失效可能是编辑器延迟写入导致 inotify 没触发，404 页面不显示大概率是 run.mode = prod 被后定义的区块覆盖了——这些细节不盯着看日志和路径，很容易反复试错。
