scc：用纯 Go 重写代码统计，把 COCOMO 和复杂度塞进一个命令
Sloc、Cloc 和 Code：scc 是一个非常快速、准确的代码计数器，具有用纯 Go 编写的复杂性计算和 COCOMO 估计。
秒懂
- 它是什么？
- scc 是一个用纯 Go 实现的代码计数器，目标是成为最快的同类工具，同时附带 COCOMO、LOCOMO 估算和复杂度计算。本文基于其 README 与仓库信息，拆解它的定位、用法和值得警惕的取舍。
- 适合谁用？
- scc 适合需要快速统计多语言代码量、并希望在同一命令里拿到 COCOMO 和复杂度估算的开发者，尤其是 CI 脚本或本地快速扫描场景。它不适合需要精确 cyclomatic complexity 的团队，因为文档明确说明复杂度只是估算，不是精确计算。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
一个命令，从行数到成本估算
scc 解决的问题很具体：你需要知道代码库里有多少行代码、多少注释、多少空白，但不想为每个指标分别装工具。它把行数统计、复杂度估算、COCOMO 成本模型和 LOCOMO 的 LLM 开发成本估算都塞进一个二进制。目标用户是那些在 CI 里跑代码统计、或者想快速评估一个陌生仓库规模的开发者。README 里明确说它的目标是成为最快的代码计数器，同时附带这些额外计算。这听起来像瑞士军刀，但它的核心仍然是行数统计，其他功能是附加项。
纯 Go 实现，性能优先的设计
scc 用纯 Go 编写，没有运行时依赖。它借鉴了 tokei 和 cloc 的思路，但实现上追求速度。README 提到它驱动了 searchcode.com，说明它在真实的大规模仓库上运行过。性能是它的卖点，但文档没有给出具体基准数字，只链接了作者博客上的性能文章。从设计上看，Go 的并发模型适合并行扫描文件，scc 很可能利用 goroutine 来加速。但这也意味着，如果你在一个极小的仓库上运行，启动开销可能比 Perl 写的 cloc 更明显。速度不是免费的，它需要内存和 CPU 的配合。
安装方式多，但 Go 版本有门槛
安装途径很丰富：Go install、Snap、Homebrew、Fedora COPR、MacPorts、Scoop、Chocolatey、WinGet、FreeBSD pkg，甚至 Docker。官方推荐用 Go 工具链安装，命令是 `go install github.com/boyter/scc/v4@latest`。注意 README 明确要求 Go 版本不低于 1.25，这意味着如果你还在用老版本 Go，得先升级。Snap 安装有个坑：Snap 应用不能运行在 /home 之外，README 直接给出了这个限制。Docker 方式比较干净：`docker run --rm -it -v "$PWD:/pwd:ro" --network none ghcr.io/boyter/scc:master scc /pwd`，用只读挂载和禁用网络，适合不想污染环境的场景。
核心用法：从简单统计到 Git 洞察
基本用法就是在目录下运行 `scc`，它会递归扫描并输出表格。但真正有意思的是它的附加功能。它支持 Git 洞察报告，能按提交者或时间维度分析代码变化。HTML 报告可以生成可视化页面。输出格式不止一种，README 列出了多种格式，但没有逐一说明。对于需要集成到 CI 的工具，输出格式的灵活性很关键。你可以用 `--format` 指定输出，但具体参数名在 README 里没有给出，需要查 `--help`。这说明 README 更注重展示能力，而不是提供完整的命令行参考。
复杂度估算：是估算，不是精确计算
scc 声称能估算代码复杂度，类似 cyclomatic complexity 计算器。但 README 的用词是 "estimate"，不是 "calculate"。这是一个重要的区别。真正的 cyclomatic complexity 需要解析控制流图，而 scc 作为行数计数器，很可能用启发式规则，比如统计 if、for、while 等关键字的数量。这意味着对于复杂的控制结构，它的数字可能不准确。如果你需要精确的复杂度来驱动质量门禁，scc 不是合适的工具。它更适合给你一个粗略的复杂度信号，用来比较不同模块的相对复杂度。文档没有详细说明算法，所以实际误差范围未知。
COCOMO 与 LOCOMO：估算模型的双刃剑
COCOMO 是经典的成本估算模型，scc 实现了它，同时引入了 LOCOMO，一个针对 LLM 开发成本的估算模型。README 没有解释 LOCOMO 的具体公式，只说它是 "LOCOMO estimation for LLM-based development costs"。这暗示 scc 在面向 AI 辅助开发的场景。searchcode.com 的定位是 "structured code intelligence over any repo, built for AI agents"，所以 LOCOMO 可能是为了估算用 LLM 重写或维护代码的成本。但文档没有给出任何校准数据，你无法知道这个估算的置信度。如果你要用它来报价或做预算，最好把它当作一个粗糙的参考，而不是精确的财务预测。
ULOC 与 DRYness：衡量重复代码
scc 提供 Unique Lines of Code (ULOC) 指标，用来衡量代码库的 DRYness，即重复代码的程度。这个指标计算不重复的行数，如果 ULOC 远小于总行数，说明代码重复较多。这是一个有趣的角度，但 README 没有定义如何计算 "unique"，是按字符串精确匹配，还是忽略空白差异？这会影响结果。对于想要量化技术债的团队，ULOC 可以作为参考，但它不能替代专门的重复代码检测工具，比如 PMD 的 CPD。scc 的 ULOC 更像是一个快速信号，而不是深入的重复分析。
MCP Server 模式：为 AI 代理打开大门
v4.0.0 的发布说明里，README 提到了 MCP Server 模式。MCP 是 Model Context Protocol，用于让 AI 代理访问外部工具。scc 提供 MCP 服务器模式，意味着 AI 代理可以直接调用 scc 来获取代码统计信息，而不用解析命令行输出。这是 scc 面向 AI 场景的另一个证据。但 README 没有给出 MCP 模式的启动命令或配置示例，只有标题。如果你想用这个功能，需要去源码里找。这说明 v4.0.0 可能刚引入这个特性，文档还没跟上。对于开发者来说，这是一个值得关注的方向，但当前可用的信息有限。
编辑结论
scc 适合需要快速统计多语言代码量、并希望在同一命令里拿到 COCOMO 和复杂度估算的开发者，尤其是 CI 脚本或本地快速扫描场景。它不适合需要精确 cyclomatic complexity 的团队，因为文档明确说明复杂度只是估算，不是精确计算。也不适合对输出格式有严格定制需求的人，除非你愿意改 Go 源码重新编译。在采用前，先确认你的 Go 版本不低于 1.25，并检查你关心的语言是否在 LANGUAGES.md 中。若你主要用 Rust 或对 Unicode 边界处理有要求，tokei 可能是更稳的选择。scc 的维护活跃，v4.0.0 刚发布，但新版本可能引入行为变化，升级前应跑一遍你自己的仓库对比输出。
社区笔记