Go适合高并发网络服务，因其调度模型和net/http等标准库深度优化；但不适合脚手架或胶水脚本，因编译部署流程长、缺乏热重载支持。适合做高并发网络服务，但别拿来写脚手架或胶水脚本Go 的核心优势在调度模型和标准库对网络 I/O 的深度优化，不是语法多简洁。它天生适合长期运行、连接数多、逻辑相对清晰的服务端程序，比如 API 网关、消息中转、实时同步服务。反过来，如果项目需要快速试错、频繁调用外部 CLI、依赖大量动态加载插件，Go 反而拖慢节奏——编译、打包、调试链路比 Python/JS 长得多。常见错误现象：go run main.go 启动慢得反常，或者热重载靠 air 或 reflex 还是卡顿；本质是 Go 不鼓励“边改边跑”的开发流，它预设的场景是“构建一次，部署稳定”。Web API / RPC 服务：用 net/http 或 gin、echo 没问题，但别指望靠中间件堆出 Rails 那种生态CLI 工具：可以做，但参数解析、颜色输出、交互式提示要自己补很多轮子（spf13/cobra 是事实标准，但配置成本比 argparse 高）数据管道 / ETL：适合固定格式、高吞吐场景（如日志转发），不适合字段频繁变更、需 SQL 交互的轻量分析GC 压力小不等于内存无坑，切片和 map 是高频泄漏点Go 的 GC 确实比 Java 轻量，但开发者对内存生命周期的控制变弱了——尤其是 []byte、map[string]interface{} 这类结构，稍不注意就让旧数据被新 slice 引用住，导致整块底层数组无法回收。典型表现：服务运行几小时后 RSS 持续上涨，pprof heap 显示大量 runtime.mspan 或 reflect.Value 占用，但代码里没明显 new。立即学习“go语言免费学习笔记（深入）”；切片截取后别直接返回子切片：用 append([]T{}, s[i:j]...) 复制一份，避免持有原底层数组map 删除键后记得 delete(m, key)，别只置 nil；更关键的是，别把 map 当缓存用而不设限（没 TTL、没 size 控制）HTTP handler 里别把 req.Body 读到全局变量或长生命周期结构体里——它背后是 io.ReadCloser，关联着连接缓冲区goroutine 泄漏比 panic 更难发现，超时和 context 是唯一解药一个没加 context.WithTimeout 的 http.Client 调用，或一个没监听 ctx.Done() 的 for-select 循环，可能让 goroutine 永远挂起。它们不报错、不 crash，只悄悄吃掉栈内存和调度开销，直到 runtime: goroutine stack exceeds 1000000000-byte limit 才崩。 Vozo Vozo是一款强大的AI视频编辑工具，可以帮助用户轻松重写、配音和编辑视频。