composer archive 不提供源码保护，仅支持排除式裁剪，生成的压缩包中所有 PHP 文件均为明文可读；其作用是剔除非必要文件（如 tests/、.github/），实现信息收敛而非安全加固。
composer archive 本身不提供源码保护，它只做“排除式裁剪”，不是加密、混淆或权限控制工具。 你不能靠它防逆向、防盗用、防查看逻辑——它生成的 zip/tar 里所有 PHP 文件都是明文可读的。它的实际作用只有一个：在分发源码包时，把非必要文件（比如测试、文档、CI 配置）干净地剔除掉，让接收方拿到的包更小、更专注、更符合语义。
为什么 composer archive 不等于代码保护
很多人误以为加了 archive.excludes 或 .gitattributes export-ignore 就能“隐藏核心代码”，其实完全相反：
-
composer archive只决定“哪些文件进压缩包”，不改变文件内容——所有打包进去的.php文件仍是原样、未加密、无权限限制 - 它不阻止用户解压后直接
grep、php -l或 IDE 打开分析 - 如果你没在
composer.json的autoload里声明某目录，它可能根本不会被打包；但一旦进了包，就毫无防护 - 所谓“保护”仅体现在：不把
tests/里的断言逻辑、.env.example里的结构暴露出去——这是信息收敛，不是安全加固
archive.excludes 和 .gitattributes export-ignore 哪个更可靠
两者都生效，但优先级和适用场景不同：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
.gitattributes是 Composer 内部硬编码支持的最高优先级过滤机制，路径匹配严格（前缀匹配，不支持**），且无需 git 提交即可被composer archive读取 -
archive.excludes是 composer.json 顶层配置，只对当前项目生效，支持*和?，但不支持递归通配符（docs/**无效，得写docs/*、docs/**/*.md这种写法不识别） - 如果两者冲突，
.gitattributes胜出；若项目没用 git，.gitattributes完全失效，只能依赖archive.excludes - 注意：
archive.excludes在私有包中才真正起效——你写在自己项目根目录的 composer.json 里，对composer install别人的包毫无影响
真正想隐藏逻辑？别用 archive，换方案
如果你的目标是防止下游看到实现细节（比如 SDK 中的鉴权算法、密钥处理流程），composer archive 是走错路了：
- PHP 代码混淆可用
php-obfuscator或ionCube，但会破坏调试和兼容性，且无法防高级逆向 - 敏感逻辑应抽成独立服务，通过 API 调用，而非发布源码
- 私有包 + 私有仓库（如 Satis + Basic Auth）能控制“谁可以下载”，但下载后仍是明文——这属于访问控制，不是源码保护
- 若必须发源码，可在
composer.json中删掉关键目录的 autoload 声明，并确保它们不在archive.excludes白名单里——这样连打包都不会打进去，比打包后再删更彻底
最常被忽略的一点：archive 生成的包名和内部目录结构完全由 composer.json 的 name 和 version 决定，而不是当前 git 分支或 tag。如果你没填 version，或者用了 dev-main 这类不稳定版本号，下游 require 时可能拉不到预期包——这不是保护，是部署事故。
