composer不安装phalcon框架本身，只校验ext-phalcon是否启用；必须在composer.json的require中声明"ext-phalcon": "*"以触发环境检查，否则部署时可能静默失败。
Composer 不安装 Phalcon 扩展，只校验 ext-phalcon 是否启用
Phalcon 是 C 编译扩展，不是纯 PHP 包，composer require phalcon/phalcon 会失败或引入已废弃的包（如旧版 phalcon/phalcon），必须避免。Composer 唯一能做的，是声明平台依赖并触发环境检查。
关键操作是往 composer.json 的 require 字段里加："ext-phalcon": "*"。不加这行，composer install 在本地看似成功，但部署到新服务器时不会报错，new PhalconMvcApplication() 直接 fatal error —— 因为没人验证 phalcon.so 是否加载。
-
"ext-phalcon": "*"必须放在require（生产依赖），不能放require-dev，否则 CI/CD 流水线跳过检查 - 若项目还依赖
ext-pdo_mysql、ext-redis等，也应一并列在require里，统一约束运行环境 - 验证是否生效：执行
composer install后，看终端输出是否有ext-phalcon: *并标记为 satisfied；再手动运行php -m | grep phalcon确认扩展真实存在
devtools 和 ide-stubs 必须用 --dev 安装
phalcon/devtools 是命令行脚手架（生成控制器、模型等），phalcon/ide-stubs 是给编辑器提供类型提示的 stub 文件，二者都不参与运行时逻辑，也不该打进生产镜像。
正确做法是分开安装：
-
composer require phalcon/devtools --dev→ 安装后可用phalcon命令创建项目骨架 -
composer require phalcon/ide-stubs --dev→ VSCode 或 PhpStorm 就能识别PhalconMvcController等类和方法签名 - 删掉这两个包，不影响应用启动；但误装进
require会导致生产环境多出无用依赖，增大镜像体积
autoload 配置必须匹配实际目录结构
Phalcon 项目没有强制目录规范，但 Composer 自动加载路径写错，就会 Class not found。常见错误是 PSR-4 映射与物理路径不一致。
比如你把控制器全放在 app/controllers/ 下，命名空间是 AppControllers，那 composer.json 里就得写："App\": "app/"，而不是 "App\": "src/" 或漏掉结尾斜杠。
- 如果用
src/目录，就配"App\": "src/"；如果用app/，就配"App\": "app/" - 全局函数文件（如
app/functions.php）需用"files"类型 autoload："files": ["app/functions.php"] - 改完 autoload 后，务必运行
composer dump-autoload -o生效，否则修改不生效
集成第三方包（如 GraphQL、Monolog）要避开版本冲突
Phalcon 本身不依赖 Composer，但现代项目常集成 webonyx/graphql-php、monolog/monolog 等通用组件。这类包与 Phalcon 共存时，容易因 PHP 版本或依赖传递引发冲突。
典型踩坑点：
-
webonyx/graphql-php要求 PHP ≥ 8.1，而 Phalcon 5.x 支持 PHP 8.0+，若项目锁死 PHP 8.0，composer require webonyx/graphql-php会失败 -
monolog/monolog与 Phalcon 自带的日志组件无冲突，但若同时用PhalconLogger和MonologLogger，要注意日志 handler 配置别覆盖彼此 - Phalcon 4.x 用户注意：
phalcon/incubator已弃用，不要composer require phalcon/incubator，改用官方维护的phalcon/php接口包（仅提供类型定义）
最易被忽略的是：所有这些依赖管理的前提，是 php -m | grep phalcon 有输出。没这一步，后面全是空中楼阁。
