http.ListenAndServe 是阻塞调用，会一直监听端口直至出错或关闭；路由不支持/:id需手动解析或用gorilla/mux；读JSON要用json.NewDecoder避免body耗尽；Linux绑定位端口需权限或改用高位端口。
为什么 http.ListenAndServe 启动后程序就卡住不往下执行
因为 http.ListenAndServe 是阻塞调用，它会一直监听端口、处理请求，直到发生错误或被主动关闭。这不是 bug，而是设计使然——Go 的 HTTP 服务默认以单 goroutine 启动并接管整个生命周期。
- 若后续有初始化逻辑（比如加载配置、连接数据库），必须在
http.ListenAndServe前完成 - 想“后台启动”服务？得显式起 goroutine：
go http.ListenAndServe(":8080", nil)，但要注意主 goroutine 不能立即退出，否则进程结束，服务就没了 - 更稳妥的做法是用
http.Server结构体，配合server.ListenAndServe()或server.Serve(ln)，便于后续调用server.Shutdown
如何让路由支持路径参数（如 /user/:id）
标准库 net/http 不支持带冒号的动态路由语法，/:id 这种写法直接注册会 404。
- 简单场景：用
http.ServeMux的通配匹配（如/user/），再手动从req.URL.Path截取和解析 - 需要多级嵌套或正则匹配？推荐轻量第三方路由，比如
gorilla/mux：r := mux.NewRouter()
r.HandleFunc("/user/{id:[0-9]+}", handler).Methods("GET") - 注意：任何路由库都只是封装了
http.Handler接口，最终仍要交给http.ListenAndServe或http.Server启动
如何正确读取 POST 请求的 JSON 数据
常见错误是直接用 io.ReadAll(req.Body) 但没重置 req.Body，导致后续中间件或框架无法再次读取。
CXF创建webservice服务端 中文WORD版
下载
本文档主要讲述的是CXF创建webservice服务端；Apache CXF是一个开源的 Services框架，CXF帮助您利用 Frontend 编程 API 来构建和开发 Services ，像 JAX-WS 。这些 Services 可以支持多种协议，比如：SOAP、XML/HTTP、RESTful HTTP 或者 CORBA ，并且可以在多种传输协议上运行，比如：HTTP、JMS 或者 JBI，CXF 大大简化了 Services 的创建，同时它继承了 XFire 传统，一样可以天然地和 Spri
- 标准做法：先检查
Content-Type是否为application/json - 用
json.NewDecoder(req.Body).Decode(&v)，它内部会按需读取，且不破坏 body 流 - 如果确实需要多次读 body（比如日志 + 解析），得用
io.ReadAll把内容存下来，再用bytes.NewReader重建req.Body：
body, _ := io.ReadAll(req.Body)
req.Body = io.NopCloser(bytes.NewReader(body))
Decode 返回非 nil 错误为什么本地能跑，部署到 Linux 服务器就报 listen tcp :80: bind: permission denied
Linux 下，非 root 用户默认不能绑定 1024 以下端口，:80 就在此列。
立即学习“go语言免费学习笔记（深入）”；
- 最简单：改用高位端口，比如
:8080，前端用 Nginx 反向代理转发 - 不想改端口？可给二进制文件加 capability：
sudo setcap 'cap_net_bind_service=+ep' ./myserver
，这样普通用户也能 bind 80 - 不建议用
sudo ./myserver启动，权限过大且不利于进程管理 - 容器环境（Docker）中，可通过
--cap-add=NET_BIND_SERVICE或直接用高位端口更安全
