composer.json是项目对依赖和加载规则的「事实声明」，非普通配置文件；手写易因全角引号、BOM、尾逗号、name格式错误等导致JSON解析失败，90%报错源于语法或语义错误而非逻辑问题。
composer.json 不是配置文件，是你项目对依赖和加载规则的「事实声明」——写错一个字段，composer install 就可能装出跑不起来的环境。
为什么手写 composer.json 容易失败
90% 的报错不是逻辑问题，而是 JSON 语法或路径语义错误：JSON decode error: Syntax error 这类提示根本不告诉你哪一行错了。常见原因包括：
- 复制粘贴带了全角引号（“”）或 BOM 头
- 用 Excel/Word 保存导致编码污染
- 末项多加了逗号（
"php": "^8.1",❌） -
name字段留空或格式不对（如写成"myapp"而非"vendor/myapp"）
实操建议：新建文件时，第一行就写 {，用 VS Code 等编辑器选「UTF-8 无 BOM」，所有字符串必须用英文双引号，键名也必须加引号（"autoload" ✅，不能写 autoload ❌）。写完立刻去 jsonlint.com 校验。
require 和 require-dev 怎么分才不炸上线
分界线不是“本地还是线上”，而是「PHP 执行业务代码时会不会 new/use/调用它」。
-
guzzlehttp/guzzle出现在src/Service/ApiClient.php里 → 必须进require -
phpunit/phpunit只在tests/下被use→ 只能放require-dev -
symfony/console如果只在bin/console里用，且该脚本不上生产 →require-dev；但如果控制器里也用了CommandBus→ 得进require
验证方法：执行 composer install --no-dev && php -r "new AppHttpController();"，能成功实例化才说明边界清晰。CI 构建失败却本地正常？先查 require-dev 里有没有漏进 require 的运行时依赖。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
autoload 配完 Class not found？问题八成在这儿
Composer 不会在运行时报“autoload 配错了”，只会冷冰冰抛 Class not found。关键细节：
-
psr-4的 namespace 必须以反斜杠结尾："App\": "src/"✅，"App"或"App\"（多一个） ❌ - 路径必须存在、可读，且末尾带正斜杠：
"src/"✅，"src"或"./src/"❌ - 路径始终相对于
composer.json所在目录，不是当前工作目录或vendor/ - 改完后必须手动执行
composer dump-autoload，install或update不会自动触发 -
files列表里的 PHP 文件，每次请求都会include_once，别塞数据库连接或 heavy 初始化逻辑
composer.lock 必须提交，且 CI 必须用它安装
composer.json 只写模糊版本（如 "^2.0"），而 composer.lock 锁死每个包的确切版本号、哈希值和完整依赖树。没它，不同机器上 composer install 可能装出行为不一致的依赖。
- Git 提交时必须包含
composer.lock - CI 流水线里必须用
composer install（而非update），确保装的是 lock 文件里锁定的版本 - 本地改了
composer.json后，要先composer update更新 lock，再提交两者
最容易被忽略的一点：很多人以为改完 autoload 或增删 require 后跑一次 install 就够了，其实 dump-autoload 和 lock 更新是两个独立动作，漏掉任何一个，都可能导致类找不到或环境不一致。
