Composer标准骨架与商业动作捕捉库完全无关，前者是PHP依赖管理工具拉取的代码模板，后者属于Unity/Unreal等引擎生态；Composer仅负责安装依赖，不参与动画、物理或硬件控制。
Composer 标准骨架（如 Laravel、Symfony、ThinkPHP 的 create-project 骨架）和“商业动作捕捉库”完全无关——后者是 Unity/Unreal/MotionBuilder 里的东西，前者是 PHP 依赖管理工具拉取的代码模板。所谓“完美兼容”，其实是把两个不同生态的概念硬凑在一起造成的误解。
composer create-project 比 composer init 快且稳
标准骨架的核心价值不是“功能多”，而是开箱即用的确定性：
-
composer create-project laravel/laravel myapp会自动执行composer install、生成vendor/autoload.php、运行框架预设脚本（比如php artisan key:generate），一步到位 -
composer init只生成空的composer.json，后续要手动require框架、配置 autoload、处理 Git 忽略、补环境变量——新手常卡在Class 'App\Http\Controllers\Controller' not found - 骨架自带
composer.lock，确保所有协作者安装完全一致的依赖版本；手动 init 后若漏 commit lock 文件，CI 构建就可能失败
所谓“兼容动作捕捉库”实际指什么
搜索中出现的“Composer 兼容动作捕捉库”，99% 是混淆了工具链。真实场景里 Composer 只可能出现在以下环节：
- 后端 API 层：用
composer require ros2php/ros2-client封装 ROS2 指令下发，但动作本身由机器人控制器执行 - 通信桥接层：装
guzzlehttp/guzzle或ext-soap调用 ABB RobotStudio 的 RAPID Web Services 接口 - 日志与调度：用
monolog/monolog记录抓取时间戳，symfony/process安全调用ros2 action send_goal - 绝对不涉及：Three.js 的
mesh.position.set()、Unity 的Animator.SetIKPosition()、MotionBuilder 的 FBX 动作导入
容易踩的坑：以为装了包就能驱动硬件
常见错误现象包括：
- 执行
composer require robotics/ik-solver后，在 PHP 里 new 出一个GripperController，结果报Class 'Robotics\Gripper' not found—— 因为这包根本不存在，或只是个空命名空间占位符 - 看到
composer.lock里有"ros2php/ros2-client": "1.2.0"，就以为 PHP 进程能直接控制伺服电机——其实它只发 HTTP 请求或调用 CLI 命令，底层仍是 ROS2 daemon 在跑 - 在 Laravel 控制器里写
exec('ros2 topic pub /gripper_cmd std_msgs/msg/Float64 "{data: 0.02}"')，却没配好系统用户权限或 PATH，导致命令静默失败
真正决定抓取是否精准的，从来不是 composer.json 里写了什么包，而是 URDF 中的 origin rpy 是否写反、ROS2 的 tf2 时间戳是否同步、以及你有没有在 PHP 侧用 json_encode($pose, JSON_PRESERVE_ZERO_FRACTION) 保住浮点精度。Composer 只管“装”，不管“动”。
