# Go Development > 当用户在 Go 项目中进行代码实现、重构、调试、测试、包设计、并发处理、性能优化、模块管理，或需要遵循仓库现有 Go 工程规范时使用此 skill。适用于涉及 Go 源码、go.mod、单元测试、接口设计、goroutine、context、channel、错误处理或项目级 Go 架构的问题。 - Skill: `reaperhero/go-development` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add reaperhero/go-development` - Raw SKILL.md: https://api.skillmd.com/api/skills/reaperhero/go-development/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: reaperhero (https://skillmd.com/u/reaperhero) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/reaperhero/go-development --- # Go 开发 ## 概述 当任务目标不是只做解释，而是要在 Go 项目里完成实际开发工作时，使用这个 skill。 默认目标是： - 先理解现有包结构和代码风格 - 做最小且正确的改动 - 保持与仓库现有模式一致 - 在有清晰切入点时补充或更新测试 - 用最小但有效的命令完成验证 ## 适用场景 当用户希望你： - 实现或修改 Go 代码 - 修复 Go Bug - 新增或更新 Go 测试 - 重构包、接口或模块边界 - 优化并发、上下文传递或错误处理 - 分析 `go.mod`、`go.sum`、构建标签或包结构 - 解释 Go 项目的调用链或架构设计 - 排查性能或内存问题 ## 工作原则 - 改代码前先读本地代码，不要先入为主。 - 仓库已有风格优先于通用最佳实践。 - 除非任务明确要求，否则尽量保持现有 API 和包边界稳定。 - 优先写清晰、直白、可维护的代码，而不是炫技代码。 - 不引入没有必要的抽象。 - 能提炼成纯函数的逻辑，优先提炼后再测试。 - 修改应尽量小，避免把重构和行为变化混在一起。 - 尊重现有命名、文件组织和错误处理风格。 ## 标准工作流 ### 1. 建立上下文 优先检查： - `go.mod` - 目标包及其相邻文件 - 当前目录已有测试 - 相关接口、结构体和调用路径 在动手前先回答这几个问题： - 这段行为归哪个包负责 - 最小可行改动是什么 - 仓库里有没有现成模式可以复用 - 是否已有 helper、抽象或公共逻辑可以沿用 ### 2. 设计改动 优先： - 最小 diff - 稳定的导出 API - 尽量不影响现有调用方 - 只在确实有助于测试时才提炼纯逻辑 避免： - 没必要的大范围跨包改造 - 无必要引入第三方库 - 把“重构”和“改行为”混成一次提交 - 为了测试而过度设计 mock 结构 ### 3. 实现代码 实现时应注意： - 尽量让零值有意义 - 合适时把 `context.Context` 放在第一个参数 - 返回错误时在必要处补充上下文 - 正常控制流不要依赖 panic - goroutine 的生命周期、退出条件和取消路径要清晰 - 共享状态的同步方式要显式、易懂、可验证 ### 4. 编写测试 优先遵循仓库风格。 默认测试规范： - 优先使用 table-driven tests - 使用 `tests := []struct { ... }` - 使用 `t.Run(tt.name, func(t *testing.T) { ... })` - 断言风格尽量统一为 `got` / `want` - 错误信息统一为 `xxx() = ..., want ...` - 优先写纯单元测试，避免依赖外部服务、真实数据库、网络和环境状态 - 重点覆盖边界条件、空值、重复值、排序、去重、保持原值等核心行为 如果目标目录已经有测试： - 模仿现有命名方式 - 模仿现有断言风格 - 模仿现有 helper 和 fixture 组织方式 - “按仓库风格写测试”优先于“只要测试能过” ### 5. 验证结果 优先运行最小验证命令： - `go test ./path/to/package` - 必要时再运行 `go test ./...` - 如果只是构建问题，可先做定向 build - 如果只是某个函数或某个包改动，不要一上来全量跑 如果因为环境、依赖或时间原因无法验证，要明确说明。 ## Go 代码风格要求 ### 包设计 - 一个包只负责一类清晰职责。 - 避免循环依赖，抽象应放在真正拥有该行为的边界上。 - 导出面尽量小。 - 在真正需要抽象给调用方之前，优先使用具体类型而不是接口。 ### 错误处理 - 错误应返回，不要静默吞掉。 - 传播错误时在必要场景补上下文。 - 除非仓库已有一致模式，否则不要同时 log 再 return 同一个错误。 - 只有在调用方确实需要判断时才使用 sentinel error。 - 只有在行为依赖结构化错误信息时才引入自定义错误类型。 ### 并发 - 每个 goroutine 都应有明确生命周期。 - 优先使用 `context` 做取消控制。 - channel 用于协调，不要把它当成所有共享状态问题的通用替代。 - 当互斥锁是最简单正确的方案时，直接用 mutex。 - 避免在超时、提前返回或消费方退出时泄漏 goroutine。 ### 测试 - 测试应尽量小、稳定、确定。 - 除非仓库本来就是这么测，否则避免依赖真实网络、数据库、文件系统和环境变量。 - 能提炼纯逻辑时，优先提炼后测试，而不是堆复杂 mock。 - 只有任务与性能有关时才补 benchmark。 ## 输出要求 完成任务后，输出应包含： - 改了什么 - 关键假设是什么 - 做了哪些验证 - 如果测试没覆盖到，剩余风险在哪里 ## Prompt 示例 - `Use $go-development 修复当前包里的这个 bug，并补充聚焦测试。` - `Use $go-development 按仓库风格重构这段 Go 逻辑，但不要改变行为。` - `Use $go-development 为这个目录补 table-driven tests。` - `Use $go-development 分析这段调用链，并解释包结构设计。` ## Resources - 当需要更细的测试规范时，读取 [references/testing.md](references/testing.md)