go中不能直接套用python线程阻塞模型，需用信号量或waitgroup+channel限流、http.client复用连接、channel+select替代async/await实现并发控制。
Python线程阻塞模型在Go里直接套用会卡死
Python里习惯用threading.Thread起一堆线程跑IO任务，比如批量调HTTP接口。到了Go，如果照搬思路写一堆go func() { http.Get(...) }()，表面看是并发了，但实际可能瞬间创建几百个goroutine，又没控制资源，导致DNS解析超时、连接池耗尽、甚至被目标服务限流拉黑。
根本区别在于：Python线程是OS级重量资源，天然有数量压制；而goroutine是用户态轻量调度单元，不设防就容易“泛滥成灾”。
- 必须显式用
semaphore或sync.WaitGroup+ 通道做并发数限制，例如控制最多10个并发HTTP请求 - 别依赖
time.Sleep模拟等待——Go里该用select配合time.After做超时控制 - Python的
requests.Session复用连接，在Go里对应的是http.Client实例复用，且要配置Transport.MaxIdleConns等参数，否则每个goroutine都新建TCP连接
从async/await到channel+select的控制流迁移
Python的async def函数靠事件循环隐式挂起，Go没有全局事件循环，所有异步协作必须靠channel显式传递信号。比如Python里常见的“等多个API返回后合并结果”，在Go里不能写await a(); await b(); await c()串行等，也不能靠asyncio.gather自动调度。
正确路径是：启动goroutine发请求，把结果或错误发到同一个chan Result，主goroutine用for i := 0; i 收齐三个响应。
- channel容量要明确：无缓冲channel会阻塞发送方，直到有接收方就绪；有缓冲（如
make(chan int, 10)）可缓解突发流量，但不解决逻辑耦合 -
select默认非阻塞需加default分支，超时控制必须用case ，不能用<code>time.Sleep阻塞整个goroutine - Python的
async with资源自动释放，在Go里得靠defer+ 显式Close()，尤其文件、数据库连接、HTTP响应体
context.Context不是装饰器，是贯穿全链路的取消凭证
Python里用@timeout(5)或asyncio.wait_for包一层就完事，Go的context.Context必须手动传入每个可能阻塞的函数——http.NewRequestWithContext、db.QueryRowContext、甚至自定义函数参数里也得加ctx context.Context。
漏传一个，超时或取消信号就断在那一层，上游永远等不到响应。
- 不要在函数内部
context.Background()硬编码，除非确定不需要继承父上下文 - 子goroutine必须用
ctx, cancel := context.WithCancel(parentCtx)派生，并在退出前调用cancel()，否则泄漏context引用，拖慢GC - HTTP handler里拿到的
r.Context()自带请求生命周期绑定，直接透传即可，不用另建
JSON序列化差异导致字段丢失或panic
Python的json.dumps(obj, default=str)几乎总能转成功，Go的json.Marshal遇到未导出字段（小写首字母）、map key非字符串、嵌套循环引用会直接panic，而且默认忽略零值字段（omitempty），跟Python默认行为不一致。
- 结构体字段必须大写开头，且加
json:"field_name"标签，否则json.Marshal输出空对象 - 需要序列化零值字段（比如
false、0、""）时，去掉omitempty，或用指针类型（*bool）配合json:",string"处理字符串化布尔 - 动态key的map（如
map[string]interface{}）能用，但深层嵌套时易panic，建议用json.RawMessage延迟解析不确定结构
协程不是魔法，是把调度权从解释器手里拿回来——代价是每一步都要自己决定谁发、谁收、谁停、谁清理。最常被跳过的其实是http.Response.Body.Close()和context.CancelFunc调用，这两个点漏掉，服务跑两天就开始OOM或者hang住。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
