不能直接在旧项目执行 composer install，因为多数遗留PHP项目无composer.json且不遵循PSR自动加载规范，会导致找不到文件或类冲突；需先创建最小composer.json、配置classmap或files autoload、确保vendor/autoload.php优先加载，并处理__autoload等遗留加载机制。
为什么不能直接在旧项目里执行 composer install
因为绝大多数遗留 PHP 项目（尤其是 2010 年代初的 CodeIgniter 2.x、Zend Framework 1、自研 MVC）根本没定义 composer.json，更没有遵循 PSR-0/4 自动加载规范。直接运行 composer install 会报错 Could not find a composer.json file，甚至可能因旧代码里存在 require_once 'xxx.php' 和 Composer 的 autoloader 冲突，导致类重复声明或找不到类。
关键不是“能不能装”，而是“装了谁来加载、怎么和现有逻辑衔接”。必须先让 Composer 加载器和旧系统共存，而不是替代。
- 先手动创建最小可用的
composer.json，仅声明autoload的psr-4或classmap，不引入任何新包 - 在入口文件（如
index.php）中，确保require 'vendor/autoload.php'在所有旧 require/require_once 之前执行，否则旧代码可能提前加载同名类，导致 Composer 自动加载失效 - 若旧项目用的是全局函数或静态类，可先用
filesautoload 类型引入，例如："files": ["helpers/common_helper.php"]
如何让旧类名被 Composer 自动加载识别
旧项目通常用下划线命名（My_Class_Name）或无命名空间，而 Composer 默认只处理 PSR-4 格式（Vendor\Package\ClassName）。硬改所有类名不现实，也不安全。
更可行的做法是用 classmap 生成器：它不依赖命名规则，而是扫描指定目录，把每个 .php 文件里的 class 声明原样记录进 vendor/composer/autoload_classmap.php。
- 在
composer.json中添加："classmap": ["application/libraries/", "application/models/"]（路径按你实际目录调整） - 运行
composer dump-autoload -o，生成优化后的 classmap - 验证方式：写个测试脚本
var_dump(class_exists('User_model'));，应返回true；再确认该类实例化后方法可正常调用 - 注意：
classmap不支持动态新增文件，每次增删类文件后都得重新运行dump-autoload
逐步替换旧依赖：从 monolog/monolog 这类无侵入工具开始
别一上来就换数据库抽象层或路由系统。优先选“只加不改”的工具类库——它们不改变请求生命周期，不接管输出，只提供更好用的辅助能力。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
比如日志：旧项目常用 error_log() 或自写 log_message()，功能弱且难维护。换成 monolog/monolog 几乎零风险：
- 安装：
composer require monolog/monolog - 在配置初始化处创建实例：
$logger = new \Monolog\Logger('main');，再加一个StreamHandler输出到文件 - 旧代码中仍可继续用原有日志函数；新模块、新接口统一用
$logger->info()，形成渐进式覆盖 - 后续可扩展：加 SlackHandler、ElasticsearchHandler，都不需要动老逻辑
类似安全、HTTP 客户端（guzzlehttp/guzzle）、配置加载（symfony/yaml）也都属于这一梯队，可按需单点切入。
迁移过程中最易忽略的陷阱：include_path 和 __autoload 冲突
很多遗留系统依赖 set_include_path() 或自定义 __autoload() 函数加载类。Composer 的 vendor/autoload.php 会注册自己的 spl_autoload_register()，但旧 __autoload 若未被显式注销，PHP 7.2+ 会报 Deprecated: __autoload() is deprecated，PHP 8+ 则直接 fatal error。
- 检查入口文件或公共配置中是否调用了
set_include_path()，如有，建议注释掉或移至 Composer autoloader 之后（但它已无必要） - 搜索全项目是否存在
function __autoload，找到后用spl_autoload_register(function ($class) { ... })替换，并确保只注册一次 - 更稳妥做法：在
vendor/autoload.php引入后，立即调用spl_autoload_unregister('__autoload');（如果确定旧函数不再需要） - 临时调试技巧：在关键位置加
var_dump(spl_autoload_functions());查看当前所有注册的自动加载器顺序和内容
这一步不解决，后续引入任何带命名空间的新包都会出现类加载混乱，而且错误表现不稳定——有时能加载，有时提示 Class not found，查半天发现是两个 autoloader 同时抢着解析同一个类名。
