不推荐在新项目中使用 Dingo API，因其自2021年起已停止维护且不兼容新版Laravel和PHP；Laravel原生API支持完善，替代方案如Sanctum、JsonResource等更现代可靠。
为什么现在不推荐在新项目中用 Dingo API
Dingo API 曾经是 Laravel 社区最流行的 RESTful API 扩展包，但它早在 2021 年就停止维护（dingo/api 最后一次发布是 v3.0.0-alpha5），官方 GitHub 仓库已归档。Laravel 自 5.5 起原生强化了 API 支持（如 Route::middleware('api')、ResponseFactory 的 JSON 默认行为、API 资源类 JsonResource），8.x+ 更内置了 RateLimiter、Sanctum 和 Passport 等完整认证方案。
继续用 Dingo 会遇到这些实际问题：
-
composer require dingo/api在 Laravel 9/10 下大概率报依赖冲突（它锁死illuminate/*: ^5.5|^6.0|^7.0|^8.0） - 无法兼容 PHP 8.2+ 的严格类型检查（比如
AbstractProvider::register()返回类型缺失） - 文档过时，Stack Overflow 上多数答案对应 Laravel 5.x，
API_PREFIX、API_VERSION这些配置项在新版 Laravel 中早已被更灵活的路由分组替代
用原生 Laravel 实现 Dingo 的核心功能
Dingo 最常被依赖的几个能力：版本化路由、响应格式自动协商、异常统一 JSON 化——其实几行原生代码就能覆盖：
-
版本化路由：不用
apiVersion()，直接用路由前缀 + 中间件分组：Route::prefix('api/v1')->middleware('api')->group(function () { Route::get('/users', [UserController::class, 'index']); }); -
响应自动 JSON 化：Laravel 默认
api中间件已启用StartSession和ThrottleRequests，返回数组或模型会自动转为 JSON（无需response()->json()显式调用） -
异常 JSON 化：修改
app/Exceptions/Handler.php的render()方法：if ($request->is('api/*') && $exception instanceof \Exception) { return response()->json(['message' => $exception->getMessage()], 500); }
替代 Dingo 的现代方案选型建议
如果确实需要 Dingo 那类“开箱即用的 API 框架感”，优先考虑这些仍在活跃维护的方案：
-
laravel/sanctum：轻量认证，适合 SPA 或移动端，配合原生路由完全够用 -
spatie/laravel-responsecache：给 API 加缓存，比 Dingo 的Cache-Control头控制更可控 -
darkaonline/l5-swagger：生成 OpenAPI 文档，Dingo 的api-docs功能已被它全面取代，且支持 Laravel 10 - 真要强版本控制？用
laravel-json-api（遵循 JSON:API 规范）或自己写个ApiVersionMiddleware，比硬塞 Dingo 更清晰
如果必须迁移旧 Dingo 项目
老项目里还跑着 Dingo？别重写，先做最小化剥离：
- 把
dingo/api的所有路由从routes/api.php移到标准Route::prefix('api/v1')分组下 - 删掉
config/api.php和app/Providers/ApiServiceProvider.php - 替换响应构造：把
$this->response->array(...)改成response()->json(...)，把$this->response->errorNotFound()改成abort(404, 'Not found') - 认证逻辑迁移到
sanctum：auth:sanctum中间件替代api.auth，TokenGuard替代 Dingo 的Auth\Provider
真正卡住的往往是自定义的 Transformer 类——它们和 Dingo 强耦合，但其实用 Laravel 的 JsonResource 重写一遍，代码量更少、IDE 支持更好、调试也更直观。
