用途：这是一份描述 Carlos Becker（@caarlos0）编程风格、约定与审查习惯的参考，用于与其结对编程、审查其 PR/issue 或向其项目贡献代码时对齐做法。他主要用 Go 构建 CLI，维护 GoReleaser、nFPM、env、svu、fang 等项目，追求长期稳定的“无聊可靠性”而非新奇。
主要原则：默认答案是“不”，每个功能都是永久维护负担，新代码需自证价值；只解决真实存在的问题；可预测、稳定、有文档胜过炫技；公共 API 保持小，通过选项/钩子/结构体标签扩展；小步频繁发布，一次提交一个改动，一个 PR 一个关注点。
Go 写法：遵循惯用 Go，使用 gofmt 与 golangci-lint；依赖尽量少，新增 go.mod 依赖需在 PR 中说明理由；错误用 errors.Is/As 与 fmt.Errorf("...: %w", err) 包装，小写、无结尾标点、说明失败原因；CLI 用 Cobra + fang；配置用结构体标签（如 env:"PORT" envDefault:"8080"）；扩展用函数式选项；测试用 testify/require 与 t.Run 子测试，表驱动或按用例拆分，每个用例用唯一假数据；修 bug 只做外科手术式改动并加回归测试，不夹带重构；非公共 API 放 internal/；泛型与接口仅在真正消除重复时使用，接口定义在消费方。
运行方式：以 make 为入口（make test、make lint、make build、make ci），CI 运行相同目标；用 GoReleaser 发布，可复现构建、交叉编译、签名；Dockerfile 固定 digest 并通过多 FROM 拉取静态二进制；GitHub Actions 做 CI，外部调用 5xx 时重试。
提交与 PR：使用带 scope 的 Conventional Commits，每个提交签名（git commit -s），一次提交一个逻辑改动，一个 PR 一个关注点，包含测试，行为变更时更新文档；非平凡改动先开 issue 说明问题、复现与方案。
审查风格：简短、具体、可操作，小改动直接给内联 diff；对无理由的新依赖、无真实用户的新配置项、混入 bug 修复的“顺手”重构、无弃用路径的破坏性变更、不真正断言行为的测试、用 interface{}/any 规避类型等会强烈反对；该肯定时肯定，但不为讨好而合并。
默认与禁忌：默认更少代码、标准库优先、函数优先于新抽象、结构体字段优先于新包、先读仓库既有模式；不要在没有证据时加重试/超时/防护，不要重写能工作的东西，不要把断言藏在测试辅助函数里，不要提交与标题无关的文件，不要承诺无法兑现的长期支持。工具方面：终端优先，fish shell、neovim、ghostty/rio，dotfiles 由约 100 行的 ./setup 脚本管理，不用 Nix/Ansible。限制：以上为个人风格约定，非强制规范，具体项目以其仓库实际配置为准。