🎯 它解决了什么问题

在 Composer Skills 出现之前，Go 程序要跟 PHP/Composer 生态交互，只能走 exec.Command + 字符串解析这条老路。这条路写起来痛苦、跑起来脆弱、维护起来心累。本页说清楚这些痛点，以及 Composer Skills 是如何一一化解的。

😩 老方法的痛苦

下面这段代码是无数 Go 项目里真实存在的写法：

// 老方法 —— 脆弱、无类型、没有错误处理
out, _ := exec.Command("composer", "audit").Output()
lines := strings.Split(string(out), "\n")
// 然后你得自己解析这些字符串……
// - 表格列宽会变
// - 中英文 locale 会变
// - Composer 版本升级会改输出格式
// - 一个字段解析错，整条流水线就静默出错

它的问题远不止"代码丑"：

🛠️ 无类型：所有东西都是 string，编译器帮不上忙，运行时才发现错。
🔒 无错误处理：exec.Command 失败被吞掉，漏洞报告变成空字符串，CI 误判"安全"。
📦 格式脆弱：Composer 升一个版本、换个 locale，正则就全崩。
🌐 跨平台坑：Windows 上没有 which、macOS 上 grep 行为不同，到处 runtime.GOOS 分支。
🤔 环境依赖：目标机器没装 Composer？程序直接挂，用户还得翻文档自己装。

😊 新方法的优雅

同样的事，用 Composer Skills 写出来是这样的：

// 新方法 —— 类型化、经过测试、自动安装
result, _ := comp.AuditWithJSON()
fmt.Printf("漏洞数: %d\n", result.Found)
for _, v := range result.Advisories {
    fmt.Printf("⚠ %s: %s (%s)\n", v.Package, v.Title, v.Severity)
}

编译器替你检查类型，结构化字段随取随用，输出格式变了也不怕——因为 SDK 内部已经适配好了。

🛠️🔒📦 痛点—解决方案对照

🛠️

手动解析 exec.Command 输出

234 个类型化 Go 方法，返回结构化结果（AuditInfo、OutdatedInfo、VersionInfo 等），编译期类型检查，告别字符串解析。

🔒

漏洞审计无结构化结果

AuditWithJSON 返回带 Found、Advisories、Severity 的结构体，可直接用于 CI 失败判定与报告生成。

📦

手写 HTTP 请求访问 Packagist

20 个类型化 API 方法直接返回 Go 结构体，搜索、统计、安全公告一行调用，纯 Go 无需 PHP。

用 Markdown 表格再对照一次，方便快速扫读：

痛点	Composer Skills 的解决方案
🛠️ 手动解析 `exec.Command` 输出	234 个类型化 Go 方法，返回结构化结果
🌐 手写 HTTP 请求访问 Packagist	20 个类型化 API 方法，直接返回 Go 结构体
🔍 "这台机器装了 Composer 吗？"	跨操作系统检测器，到处都能找到
📦 "没装 Composer，怎么办？"	自动安装器，自动下载 Composer + PHP
💻 不同操作系统要写不同代码	智能默认配置，按平台选 brew、apt 或直接下载
🔒 漏洞报告只能靠正则	`AuditWithJSON` 返回结构体，`Found`/`Advisories` 字段直读
✅ composer.json 是否合法	`ValidateStructured` 返回带错误行号的结构化结果

💡 为什么不直接调系统命令？

你可能会想："我封装一层 exec.Command 不就行了？" 现实里这一层会越长越大：

要处理 Windows 的 where vs Unix 的 which
要解析 20 个分类、上百个子命令各自的输出格式
要在 Composer 不存在时优雅降级或自动安装
要给每个命令做 Mock 以便测试
要处理超时、工作目录、环境变量、stdin

Composer Skills 把这一层做成产品：234 个方法 + 450+ 测试 + 跨平台 + 自动安装，开箱即用。你专注业务逻辑，底层脏活交给 SDK。

自己封装的真实代价

一个"看起来简单"的 composer audit 封装，算上跨平台路径检测、输出解析、错误传播、超时控制、Mock 测试，往往要写 200+ 行且持续维护。Composer Skills 已经替你写完并测过了。

🧭 下一步

🚀 准备动手？前往快速开始。
🏗️ 想理解两套 SDK 的边界？看双 SDK 架构。
📦 想了解依赖与系统要求？看安装。

🎯 它解决了什么问题 ​

😩 老方法的痛苦 ​

😊 新方法的优雅 ​

🛠️🔒📦 痛点—解决方案对照 ​