composer的“as”别名仅在repositories的package类型中生效，必须写在version字段且格式为“dev-main as 2.0.0”，require中直接使用会因语法非法报invalid version string。

composer require 里写 "as" 为什么报 Invalid version string

因为 as 不是 require 字段的合法语法。Composer 只在 repositories 中 type: "package" 的包定义里识别 as —— 它必须作为 version 字段的值出现，且格式严格为 "dev-main as 2.0.0"（注意空格）。直接在 require 里写 "monolog/monolog": "dev-main as 2.0.0"，Composer 会立刻拒绝并抛出 Invalid version string。

常见错误包括：

• 只改 require 行，漏掉 repositories 配置
• 把 as 写成 "alias": "2.0.0" —— Composer 完全忽略这个 key
• version 字段缺失，或拼写成 versions、verison

alias 生效但运行时报 Cannot declare class

这说明 as 成功骗过了依赖解析，但没解决底层加载冲突。两个同名包（比如都声明 "name": "monolog/monolog"）被同时加载时，PHP 会因重复类定义直接 fatal error。

关键点在于：alias 不改变包名、不隔离命名空间、不重写 autoload 路径。它只影响 Composer 解析阶段。

此时必须检查：

• 是否真有两个包共用完全相同的 name 字段？如果是，alias 根本无解，必须改 fork 包的 composer.json 中的 name（如改成 acme/monolog）
• 两个包的 autoload 是否映射到同一命名空间？比如都用了 "Monolog\": "src/"，就会导致类文件被重复扫描
• 执行 composer dump-autoload -o 后再测试，避免 classmap 缓存旧路径

为什么 composer show 看不到别名版本

因为 composer show 显示的是实际安装的版本，不是别名“声称”的版本。它列出的是 vendor/monolog/monolog/composer.json 里真实的 version（通常是 dev-main），而不是你用 as 声称的那个（比如 2.0.0）。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

验证 alias 是否生效，唯一可靠方式是：

• 运行 composer update --dry-run，看输出中是否显示 monolog/monolog 2.0.0（而非 dev-main）
• 检查 composer.lock 中该包条目下的 version 字段是否为 2.0.0（这是 alias 生效后的表现）
• 确认 repositories 中该包定义的 name 和 require 中完全一致（大小写敏感）
• source.reference 必须可拉取，否则 composer update 会失败，alias 也不会被应用

别名能绕过 conflict 或 PHP 版本限制吗

不能。别名只参与版本约束匹配，不干预 conflict、php、ext-* 等其他约束字段。

例如：一个包声明 "conflict": {"monolog/monolog": ">=3.0"}，即使你用 "dev-main as 3.0.0" 强行伪装，Composer 仍会拒绝安装——它先校验 conflict，再看 version。

同样，如果某包要求 "php": "^8.2"，而你本地是 PHP 8.1，加任何 alias 都无效。Composer 在解析前就已根据 PHP 版本筛掉不兼容候选。

真正容易被忽略的是：alias 不提供任何兼容层，也不校验 API 是否真一致。它只是告诉 Composer “我满足这个约束”，剩下的全是你的责任。