reflex不是go微服务内置组件，仅是外部进程监控工具；直接使用reflex -r '\.go$' -s --go run main.go会因旧进程未退出导致端口冲突、残留进程和信号丢失，必须用shell脚本封装启停逻辑并配合go服务的优雅关闭机制。
Reflex 不是 Go 微服务的内置组件，它只是个外部进程监控工具；直接用 reflex -r '.go$' -s --go run main.go 会因子进程生命周期失控导致端口冲突、残留进程、信号丢失——这是绝大多数人踩坑的第一步。
为什么 reflex 默认命令在微服务里大概率失败
微服务通常监听固定端口（如 :8080），而 reflex -s --go run main.go 启动的是新进程，但旧进程不会自动退出。操作系统层面端口被占用，新进程启动时立即报错 listen tcp :8080: bind: address already in use。这不是 Go 报错，是系统资源级冲突。
- Reflex 本身不管理子进程生命周期，
-s只是“启动一个服务进程”，不等于“优雅终止上一个” - Go 程序若没注册
os.Interrupt或syscall.SIGTERM处理逻辑，收到信号也不会主动关 server - reflex 不解析 Go 构建依赖关系，
go run main.go每次都全量编译，大型项目启动慢，热更感知延迟明显
必须加 wrapper 脚本控制进程启停
不能把重启逻辑交给 reflex 直接执行 go run，得用 shell 脚本封装启停过程，确保旧进程彻底退出后再拉起新实例。
- 新建
dev-runner.sh，加执行权限：chmod +x dev-runner.sh - 脚本内用
PIDFILE=.dev.pid记录上一个进程 PID，启动前先kill $(cat $PIDFILE 2>/dev/null) 2>/dev/null || true，再go build -o ./server . && ./server & echo $! > $PIDFILE - reflex 命令改为：
reflex -r '.go$' -s --sh ./dev-runner.sh - 务必在 Go 服务中加
signal.Notify捕获os.Interrupt，调用srv.Shutdown()，否则 kill 只是 SIGKILL，连接可能被粗暴中断
避免误监第三方目录和临时文件
默认递归监听整个项目目录，vendor/、node_modules/、编辑器备份文件（*~、.*.swp）都会触发无意义重启，拖慢开发体验。
- 用
-i参数排除路径：reflex -r '.go$' -i 'vendor|node_modules|.git|.swp|~$' -s --sh ./dev-runner.sh - 如果微服务含多个 module（如
api/、service/、pkg/），只监听主启动目录更安全：reflex -r '.go$' -g 'cmd/myapp/*.go' -s --sh ./dev-runner.sh - 注意
-g（glob）和-r（regex）不能混用；正则需转义点号，.go$才匹配以 .go 结尾的文件
Docker 环境下 reflex 必须跑在宿主机，且挂载方式有讲究
在容器里装 reflex 并监听 /app 源码？不行。Docker for Mac/Windows 的文件系统事件通知不可靠，inotify/kqueue 事件大概率丢失，reflex 会完全不响应保存动作。
- reflex 必须运行在宿主机，监听本地源码目录，通过
docker run -v $(pwd):/app挂载进容器 - 容器内服务要支持
HOST=0.0.0.0绑定，否则宿主机无法访问；别用localhost或127.0.0.1 - 构建镜像时不要 COPY
go.mod和go.sum后就go build——reflex 触发的是宿主机上的go build，容器只负责运行二进制，所以 Dockerfile 应该只做 runtime 环境准备
真正难的不是让 reflex 跑起来，而是让每次重启都不丢连接、不占端口、不漏信号。这要求 Go 服务代码本身就得为热更设计：有 Shutdown 流程、有信号注册、有 graceful 退出等待；reflex 只是那个按开关的人，不能替你写关机逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
