用 net/http 而非 Gin/Echo：能直观察路由、解析、错误处理；需手动 ParseForm、校验 json tag 与 float64 边界（NaN/Inf/范围）、小写标准化单位 map 查找、显式设置 JSON header 与状态码。
用 net/http 启服务，别碰 gin 或 echo 初期
刚写 API 时，框架会掩盖路由、请求解析、错误返回这些细节。用标准库 net/http 能一眼看清请求怎么进、响应怎么出，调试 400 或空响应时不会卡在中间件里。
常见错误现象：加了 gin 后改了路由但没生效，或 BindJSON 静默失败返回空对象；其实只是结构体字段没加 json: tag，或者没处理 io.EOF。
- 只用
http.HandleFunc+http.ListenAndServe，先跑通一个/convert?from=km&to=m&value=1.5 - 手动调
r.ParseForm()，检查r.FormValue("from")是否为空，别依赖自动绑定 - 响应统一用
json.Marshal+w.Header().Set("Content-Type", "application/json")，避免框架默认的 HTML fallback
float64 解析要防 NaN 和溢出，别信 strconv.ParseFloat(r.FormValue("value"), 64) 直接用
用户输 value=abc 或 value=1e999，ParseFloat 会返回 0, error，但 0 是合法数值，容易被当成真实输入继续算，最后返回错得离谱的结果（比如把 abc 当成 0 km = 0 m）。
- 必须检查
err != nil，且显式判断math.IsNaN(val)和math.IsInf(val, 0) - 加个简单范围限制，比如
if val 1e12就直接http.Error(w, "value out of range", http.StatusBadRequest) - 单位换算本身用预定义常量表，别现场算
1.609344这种小数——精度误差会累积，例如mile → km → mile往返可能差1e-15
单位映射用 map[string]float64 而不是 if/else 链，但 key 必须小写标准化
用户可能传 KM、km、Km，如果用 if from == "km" || from == "KM"，漏一种就 400；而 map 查找快，也方便后续加新单位。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 初始化 map 时全部转小写：
rates["km"] = 1000.0，然后查之前统一strings.ToLower(from) - 查不到就立刻返回
http.Error(w, "unknown unit: "+from, http.StatusBadRequest)，别默认 fallback 到m - 避免用
map[struct{from,to string}]float64存换算系数——内存开销大，且无法支持动态单位组合（比如新增lightyear时不用改所有键）
本地测试用 curl + http.ServeMux，别急着上 Docker 或 Nginx
上线前最常踩的坑是路径没对齐：http.ListenAndServe(":8080", nil) 用的是默认 DefaultServeMux，但你写了 http.Handle("/v1/convert", ...)，结果访问 /convert 404——因为注册的是带前缀的路径，而默认 mux 不识别。
- 测试命令用：
curl "http://localhost:8080/convert?from=kg&to=g&value=2.5"，别用浏览器直接敲，它会缓存 GET 参数 - 启动时显式传
nil或自定义http.NewServeMux()，避免和包级变量冲突 - 加一行
log.Printf("serving on :8080")，端口被占时能立刻看到listen tcp :8080: bind: address already in use错误
单位换算看着简单，但字符串标准化、浮点边界、HTTP 状态码语义这三块，随便漏一个就会让 API 在真实场景里返回“看起来对、其实错”的结果。
