Composer不识别无composer.json的PHP类库，需用path类型仓库+手动补composer.json，通过autoload.files全局引入老文件，并理清隐式依赖链。
Composer 本身不识别没有 composer.json 的 PHP 类库，不是你命令写错了，是它压根没把那堆 DB.php、Utils.class.php 当成“可管理的包”。强行 composer require 肯定报 No matching package found；硬塞 package 类型仓库又容易因 autoload 缺失导致类找不到——得先让加载器认得这些文件，再让 Composer 管得住它们。
用 path 类型仓库 + 手动补 composer.json 最稳
这是处理未提交 Packagist、无命名空间、甚至 PHP 5.2 风格类名的老库最可靠的路径。核心是绕过 Packagist 发现机制，直接告诉 Composer：“这个目录就是个包，按我写的规则加载”。
-
repositories必须设为"type": "path"，"url"指向本地目录（如./lib/legacy-db），不能是 URL 或 git 地址 - 目标目录下必须存在合法的
composer.json，哪怕原库根本没有——你要手动建一个，至少包含name、version和autoload.files -
autoload.files列出所有需全局引入的文件（如["DB.php", "MySQL.php"]），它们会在 Composer 自动加载时被require_once执行，适合含函数定义或全局常量的老代码 - 别用
psr-0：老库类名像DB_MySQL看似符合，但实际文件路径往往不匹配（比如它放在根目录而非DB/MySQL.php），强行配会加载失败
package 类型仓库只在特定场景有用
当你无法修改老库所在目录结构（比如它被部署在系统级路径 /usr/share/php/legacy），或需要指定 Git 分支/Tag 版本时，package 类型才值得考虑。但它对 autoload 定义更敏感，稍有疏漏就报 invalid package information。
- 必须显式声明
source.type（常用git或svn）、source.url和source.reference（如v1.2.0或master） -
autoload仍要完整：如果老库靠include_once 'Config.php'启动，你就得把它放进files；如果它用class DB {}且无命名空间，psr-4基本无效，别硬套 - 每次改了
repositories或require，都得运行composer update legacy/db（加具体包名），否则 Composer 可能沿用旧缓存，看似更新了实则没生效
加载后类名冲突和函数重复定义怎么破
老库常直接 define() 常量或 function_exists() 检查缺失，但 Composer 的自动加载是无条件 require 的——若多个老库都定义了同名函数（如 db_connect()），启动时直接 Fatal error: Cannot redeclare。
- 优先检查老库自身是否带防重载逻辑，没有的话，在你的
autoload.files列表里把“最基础”的文件（如公共函数集）放前面，依赖它的放后面 - 实在绕不开，用
class_alias()或封装一层代理类，把老函数包进新命名空间里调用，避免全局污染 - 别在
autoload.files里塞index.php或入口脚本——它可能执行输出、跳转或 exit，破坏框架生命周期
真正麻烦的从来不是加一行 repositories，而是老库内部隐式依赖：比如 DB.php 里写了 require 'Config.php'，但你只在 autoload.files 里加了前者，后者不会被自动加载。这种链式引用必须人工理清，逐个补全——漏一个，运行时才爆错，比语法错误更难定位。
