url路径版本控制最稳妥，需用变量路由+pattern限定；控制器中应通过命名空间隔离版本逻辑，避免if-else；header版本由中间件统一处理并校验。
URL路径版本控制是最稳妥、最易调试的方案，优先选它；其他方式要么增加中间件复杂度，要么破坏REST语义或带来兼容风险。
路由怎么配才能让 /api/v1/user/info 正确映射到 v1 版本控制器
ThinkPHP5 默认不把 v1 当作变量处理，直接写 Route::get('v1/user/info', ...) 会和普通路由冲突，且无法复用逻辑。必须用变量路由 + pattern 限定：
Route::group(['prefix' => 'api'], function () { Route::rule(':version/<module>/<action>', 'api/:module/:action')->pattern(['version' => 'v[12]']); });</action></module>-
:version不会自动注入控制器方法，得手动调用request()->param('version')获取 - pattern 必须加，否则
:version会匹配任意字符串（比如v999或xxx），导致路由误判 - 不要为每个版本单独写一堆
Route::get('v1/xxx', ...)和Route::get('v2/xxx', ...)—— 路由文件迅速失控，新增接口要改多处
控制器里怎么避免 if-else 堆出“版本判断器”
拿到 version 后硬写 if ($v === 'v1') { ... } else { ... } 是典型反模式。关键在于把差异下沉到服务层或资源层：
- 按版本建命名空间，例如
appservice 1UserService和appservice 2UserService，两者实现同一接口 - 在控制器中动态加载：
$service = new "app\service\{$version}\UserService"();，但务必先class_exists()校验，否则 500 错误不可避 - 如果只是返回字段增减，别动控制器，改用 Resource 类（如
v1/UserResource和v2/UserResource）封装输出 - 禁止在基类
initialize()或构造函数里预加载所有版本类 —— 每次请求都白跑一遍 v1+v2 初始化，性能浪费明显
Header 传 X-API-Version 怎么接入又不污染控制器
TP5 原生不解析自定义版本头，但强行在每个控制器里 $request->header('x-api-version') 会重复且易漏。统一收口在中间件最干净：
- 写一个
VersionMiddleware，handle()中提取$version = $request->header('x-api-version', 'v1') - 校验合法性：
if (!in_array($version, ['v1', 'v2'])) { throw new HttpException(400, 'Unsupported version'); } - 存入 request 属性：
$request->version = $version;，后续控制器直接用$this->request->version - 注意：中间件顺序很重要，必须在路由解析前执行，否则
Route::bind()或分组路由可能已触发，再改就晚了
真正难的不是写通某个版本，而是当 v3 上线后，v1 的验证规则、字段映射、错误码文案、甚至数据库字段别名都还在跑 —— 这些细节一旦散落在控制器里，删都删不干净。版本隔离必须从目录结构、命名空间、类加载三者同时约束，缺一不可。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
