应改用社区维护分支 kitloong/laravel-dingo-api，它兼容 laravel 9–11，解决 illuminate/support 版本冲突；需通过 middleware('api') 显式启用 dingo 功能，并使用 laravel 原生响应机制替代已移除的 $this->response 调用。
安装 Dingo API 时 composer 报 illuminate/support 版本冲突怎么办
新版 Laravel（如 10.x/11.x）默认使用 illuminate/support ^10.0 或 ^11.0，而 Dingo API 官方包（dingo/api）已多年未更新，最高只兼容到 Laravel 5.8，直接 composer require dingo/api 必然报错。
实际可行的替代路径是：放弃原版 Dingo，改用社区维护的兼容分支 —— kitloong/laravel-dingo-api，它已适配 Laravel 9–11，并保持 Dingo 的路由、版本控制、响应格式等核心行为。
- 运行
composer require kitloong/laravel-dingo-api - 发布配置：
php artisan vendor:publish --provider="KitLoong\LaravelDingoApi\DingoApiServiceProvider" - 检查生成的
config/api.php，确认'version' => 'v1'和'prefix' => 'api'符合预期
注册 API 路由时为什么 Route::api() 不生效
KitLoong 分支不再提供 Route::api() 这类自定义路由宏 —— 它复用 Laravel 原生路由，但要求所有 API 路由必须显式绑定到 api 中间件组，并通过 api 路由前缀或独立域名隔离。
正确写法是：
// routes/api.php
use Illuminate\Support\Facades\Route;
Route::middleware('api')->prefix('v1')->group(function () {
Route::get('/users', [UserController::class, 'index']);
Route::post('/posts', [PostController::class, 'store']);
});
- 不能漏掉
->middleware('api')，否则 Dingo 的请求解析（如版本提取、响应包装）不会触发 -
prefix('v1')是手动实现版本控制，KitLoong 默认不自动解析 URL 中的v1，需在控制器中用$request->route()->parameter('version')手动取值 - 若要用子域名（如
api.example.com），需在config/api.php中设'domain' => 'api.example.com'，并确保路由定义在Route::domain(...)->group(...)内
返回 JSON 响应时出现 Call to undefined method Dingo\Api\Routing\Router::response()
这是典型误用旧 Dingo 文档的结果。KitLoong 分支已移除全局 app('api.router') 和 app('api.response') 实例，也不再支持 $this->response->item(...) 这类链式调用。
现在统一走 Laravel 原生响应 + Dingo 的格式中间件：
- 控制器中直接返回数组或模型：
return ['data' => $user];或return User::first(); - Dingo 的
TransformsResponsestrait 只在你主动继承Dingo\Api\Http\Controller时才可用，但该基类已过时，不推荐 - 如需数据转换（比如加
data包裹、分页元信息），改用 Laravel 自带的 API Resource：return new UserResource($user); - 确保
app/Http/Kernel.php中api中间件组包含\KitLoong\LaravelDingoApi\Http\Middleware\RespondWithJson::class
调试时看不到 Dingo 的错误堆栈或 HTTP 状态码不对
Dingo 的异常处理层被 KitLoong 替换为 Laravel 原生异常渲染流程，所以 APP_DEBUG=true 下看到的是 Laravel 错误页，而非 Dingo 风格的 JSON error 响应。
要让 API 请求返回结构化错误（如 404 → {"message":"Not Found"}），需确保：
- 请求头带
Accept: application/json，否则 Laravel 会返回 HTML 错误页 - 在
app/Exceptions/Handler.php的render()方法中，对 API 请求强制转 JSON：
public function render($request, Throwable $e)
{
if ($request->is('api/*') || $request->expectsJson()) {
return response()->json([
'message' => $e->getMessage(),
], $e->getCode() ?: 500);
}
return parent::render($request, $e);
}
这个逻辑比依赖 Dingo 的异常处理器更可控，也避免了多层异常捕获导致状态码被覆盖的问题。
真正难搞的是版本协商和内容协商细节 —— 比如同时支持 Accept: application/vnd.app.v1+json 和 URL 版本，KitLoong 默认只认前者，后者得自己写中间件解析 Request::route('version') 并塞进请求属性里。这种定制点容易被忽略，但恰恰是 API 稳定性的关键。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
