中文目录名导致 Composer create-project 失败，主因是 PHP 旧版本 UTF-8 路径支持不全，引发 file_put_contents() 参数为空；需规避中文路径、升级 PHP 8.4+ 或显式转码，并确保钩子触发条件（type=skeleton、脚本命名正确、目标目录为空）满足。
中文环境下直接用 composer create-project 会出错，不是命令写错了，而是路径、命名空间、钩子执行这三块没对齐。
为什么中文目录名一执行就报 file_put_contents(): Filename cannot be empty
这不是 Composer bug，是底层 PHP 在 Windows 或旧版环境里对 UTF-8 路径支持不全。错误发生在 post-create-project-cmd 脚本里调用 file_get_contents() 或 file_put_contents() 时——函数传入的文件路径含中文，但 PHP 没正确解码，返回空字符串，导致写入失败。
- 临时规避：项目目录名避开中文、空格、大写字母，用
my-app这类纯 ASCII 名称 - 长期方案：升级到 PHP 8.4+（已全面修复 UTF-8 路径），或在脚本中显式转码：
mb_convert_encoding($path, 'UTF-8', 'auto') - 别依赖
getcwd()直接拼路径，改用realpath(dirname(__FILE__))获取稳定根路径
post-create-project-cmd 不执行？检查这三个硬性条件
这个钩子不是“写了就能跑”，它被 Composer 严格限制触发条件：
-
composer.json中必须有"type": "skeleton"，否则create-project根本不会加载该脚本 - 脚本必须定义在
"scripts": {"post-create-project-cmd": "php replace.php"}，名字不能写成post-create-project或post-root-package-install - 目标目录必须为空——如果已有同名文件夹且含
composer.json，Composer 会跳过整个流程，连下载都不做
常见误操作：把骨架包的 type 设成 project，结果钩子静默失效；或者在 CI 环境里没清掉缓存，反复重试仍走旧缓存逻辑。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
命名空间动态替换失败，根本原因是 name 字段含非法字符
Composer 不允许 name 字段含中文或空格，所以你不能指望用户输入 张三的项目 后，自动映射出 ZhangSanProject。真正的替换逻辑得靠脚本手动拆解：
- 从
basename(getcwd())取目录名，再用str_replace(['-', '_'], ' ', $name)+ucwords()生成 PascalCase 前缀 - 不要在骨架的
autoload.psr-4里写死"App\": "src/"，留空或设为占位符"{namespace}\": "src/" - 替换时优先处理
composer.json，再遍历src/下所有.php文件，用str_replace('{namespace}', $newNamespace, $content)
漏掉 unset($json['scripts']['post-create-project-cmd']) 是高频坑——下次 composer install 会重复执行替换，把类名覆盖成乱码。
国内网络下 create-project 卡住不动？先确认镜像和缓存状态
卡在 “Installing dependencies” 不代表命令挂了，大概率是 Packagist 直连超时。但错误不报，只干等：
- 运行
composer config -g repo.packagist，确认输出是https://mirrors.aliyun.com/composer/这类国内地址 - 若没设镜像，加参数临时指定：
composer create-project --repository=https://mirrors.aliyun.com/composer/ laravel/laravel myapp - 缓存损坏也会导致解压失败：执行
composer clear-cache再重试，别跳过这步 - Windows 用户额外检查：目标路径是否在 OneDrive 或腾讯微云同步目录下——这些同步服务会锁文件，导致
vendor/写入失败
真正麻烦的是跨平台兼容性：同一套骨架，在 macOS 上跑通的替换脚本，到了 Windows 就因路径分隔符（/ vs ）或换行符（
vs
）出错。这类细节不测到真机，光看文档永远发现不了。
