Claude能显著提升Go并发代码的正确性与性能，但需明确指定goroutine+channel或sync原语模型，主动暴露竞态点并提供race日志、trace数据等结构化信息，否则易生成不可用代码。
直接说结论：Claude 能显著提升 Go 并发代码的正确性与性能，但前提是它必须清楚你用的是 goroutine + channel 还是 sync 原语，且你得主动暴露竞态风险点——它不会自动扫描全局变量或未导出字段。
明确告诉 Claude 你用的并发模型
Go 并发有两套主流范式，Claude 对它们的理解和建议完全不同。你若只说“帮我写个并发任务处理”，它大概率默认走 goroutine + channel，但如果你实际项目里重度依赖 sync.RWMutex 或 atomic，结果就是生成的代码根本没法合入。
- 需要
channel流水线模型（如数据采集、ETL）：提示中必须出现chan、select、range over channel等关键词，例如：“用无缓冲 channel 实现生产者-消费者模式，要求消费者能优雅退出” - 需要细粒度锁控制（如高频更新的计数器、缓存桶）：必须写明 “用
sync.Map替代 map + mutex” 或 “避免在for range循环中直接传入指针给 goroutine” - 若混用两种模型（比如 channel 传结构体但内部含 mutex 字段），Claude 极易忽略深拷贝问题——这时你要手动加约束：“所有通过 channel 发送的 struct 必须可序列化，禁止含
sync.Mutex字段”
把竞态条件写成测试用例再喂给 Claude
Claude 无法静态分析出所有竞态，但它能根据你提供的失败现象反推修复方案。最有效的做法，不是问“怎么写才线程安全”，而是把已复现的 data race 日志直接扔过去。
- 复制完整的
go run -race main.go报错输出，尤其是堆栈里带Previous write at和Current read at的部分 - 附上出问题的代码片段，标出哪行读、哪行写、是否在不同 goroutine 中
- 明确指令：“这是
-race检测到的竞态，请给出三种修复方式：1. 加sync.RWMutex；2. 改用atomic.Value；3. 重构为 channel 通信，并说明每种的适用边界”
用 go test -race + go tool trace 结果引导 Claude 优化
性能瓶颈不等于 CPU 高，Go 并发慢常常卡在 goroutine 阻塞、channel 缓冲区溢出或系统调用等待上。Claude 能解读这些工具的输出，但你需要把关键信息结构化喂给它。
-
go tool trace中重点关注 “Goroutine analysis” 页面的 “Longest running goroutines” 和 “Scheduler latency” 数据，不要只截图——把数字和上下文一起描述，例如：“trace 显示 87% 的 goroutine 在runtime.gopark等待，平均阻塞 120ms，对应代码在internal/worker/pool.go:45的ch ” - 如果
go test -bench显示吞吐量随 goroutine 数增加而下降，要告诉 Claude 具体拐点：“当WORKERS=32时 QPS 达峰值 4200，升到 64 后跌至 3100，gc pause 时间从 0.8ms 升至 3.2ms” - 避免模糊表述如“太慢了”或“卡住了”，Claude 无法据此判断是调度器过载、内存分配压力大，还是 channel 死锁
最容易被忽略的一点：Claude 不会主动检查你是否在 http.HandlerFunc 里启动了未受控的 goroutine。它默认你已理解 Go HTTP Server 的生命周期管理——如果 handler 启动的 goroutine 持有 request context 外的引用，或者没做超时控制，上线后必然泄漏。这种隐式契约，必须靠你写进 CLAUDE.md 的 “Concurrency Rules” 小节，而不是等它猜。
