Laravel 13 的骨架仓库：它解决了什么问题，又隐藏了什么
语法优雅且富有表现力的 PHP Web 应用框架，简化了路由、依赖注入、ORM、数据库迁移、队列与实时事件广播。
秒懂
- 它是什么？
- laravel/laravel 是 Laravel 框架的官方应用骨架，而非框架本身。本文基于仓库说明和发布记录，剖析它的定位、启动方式、维护成本，以及它在 AI 编码工作流中的新角色。
- 适合谁用？
- laravel/laravel 适合需要快速搭建标准 PHP Web 应用的团队，尤其是那些接受 Laravel 约定、希望立即获得路由、ORM、队列和迁移能力的开发者。它不适合追求最小依赖、想完全控制目录结构的项目，也不适合已有遗留 PHP 代码库需要渐进式集成的场景。
- 能商用吗？
- 未经许可不能。GitHub 在这个仓库里没有找到许可证文件；没有许可证，默认即「保留所有权利」：你可以阅读代码，但不能复用。使用前请看看 README，或先征得作者同意。
- 还在维护吗？
- 在维护。仓库最近一次提交在 21 天前。
- 用什么语言写的？
- 主要是 Blade（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
这不是框架，是起跑线
laravel/laravel 的仓库名容易让人误以为它就是 Laravel 框架的全部。实际上，这个仓库是官方维护的应用骨架，它预置了目录结构、默认配置文件和一个可运行的入口。框架的核心代码在另一个仓库 laravel/framework 中，通过 Composer 依赖引入。README 明确列出了它解决的常见任务：快速路由引擎、依赖注入容器、多种 session 和 cache 后端、Eloquent ORM、数据库迁移、队列处理和事件广播。这些能力不是骨架本身实现的，而是它默认装配好的。对于想要快速开始一个标准 Laravel 项目的开发者，这个仓库省去了手动搭建基础结构的步骤。
骨架与框架的边界在哪里
从仓库布局和发布记录看，这个骨架仓库的职责是提供起点，而不是承载业务逻辑。它的默认分支是 13.x，最近发布了 v13.10.1，说明骨架会跟随框架主版本迭代。骨架中通常包含 app 目录、routes 目录、config 目录、public 入口文件，以及 composer.json 中指向 laravel/framework 的版本约束。当你运行 composer install 时，实际下载的是框架本体。这意味着骨架的更新节奏与框架同步，但骨架本身的改动通常是配置调整或新增默认文件。理解这个边界很重要：如果你修改了骨架中的文件，这些改动不会被框架更新覆盖，但框架升级时可能会引入与骨架默认配置不兼容的变化。
启动一个新项目的真实命令
根据 README 和 Laravel 的常规用法，创建一个新项目通常不是直接克隆这个仓库，而是使用 Composer 的 create-project 命令。标准命令是 composer create-project laravel/laravel example-app。这条命令会拉取骨架，并自动执行 composer install。之后进入项目目录，运行 php artisan serve 即可启动开发服务器。骨架中预置了 .env.example 文件，你需要复制为 .env 并配置数据库连接。对于队列和缓存，默认配置使用 database 或 file 驱动，你可以根据文档修改 config/queue.php 和 config/cache.php。这些步骤在 Laravel 官方文档中有详细说明，骨架本身不提供额外安装向导。
AI 编码工作流的新增项
README 中有一个值得注意的新章节，专门讨论 Agentic Development。它建议安装 Laravel Boost 包来增强 AI 编码代理（如 Claude Code、Cursor、GitHub Copilot）的工作效率。安装命令是 composer require laravel/boost --dev，然后运行 php artisan boost:install。Boost 提供 15 个以上的工具和技能，帮助代理遵循 Laravel 最佳实践。这是一个明确的信号：骨架仓库正在适应 AI 辅助开发的趋势。但也要看到，这个功能是可选依赖，它增加了 composer.json 中的开发依赖数量，可能拖慢 composer install。对于不使用 AI 代理的团队，这个功能没有实际价值，反而增加了维护面。
一个真实的限制：它预设了太多约定
骨架仓库的最大限制是它强加了一套目录结构和命名约定。例如，控制器默认放在 app/Http/Controllers，模型放在 app/Models，这种结构对小型项目很友好，但在大型单体或领域驱动设计中可能成为束缚。如果你需要自定义目录布局，比如将业务逻辑放在 src 目录，骨架的默认结构会带来额外调整成本。另一个限制是，骨架默认启用了大量功能，包括 session、队列、事件广播等，即使你的项目只需要简单的页面渲染，这些依赖也会被安装。对于极简主义者，这显得臃肿。README 没有提及任何轻量模式，因此如果你追求最小化，可能需要手动裁剪。
与框架本体的对比：选择的真正对象
laravel/laravel 的替代方案不是其他框架，而是直接使用 laravel/framework 并自行搭建结构。骨架仓库的价值在于它提供了一个经过测试的默认配置组合。如果你选择不使用骨架，你需要自己编写 composer.json、创建 public/index.php、配置自动加载、设置路由文件。这并非不可行，但你需要理解框架的启动流程。另一个替代方案是使用其他官方或社区提供的骨架，比如 Laravel 的 Skeleton 仓库或各种 starter kits，但那些通常包含额外的 UI 或认证功能，与这个基础骨架的定位不同。关键区别在于，这个仓库是官方维护、与框架版本同步的，而自定义结构需要你自行维护。
维护与升级的隐性成本
骨架仓库的维护成本主要体现在升级上。当 Laravel 发布新版本时，你需要更新 composer.json 中的框架版本约束，并检查骨架中的默认文件是否有变化。由于骨架的发布记录显示频繁更新（v13.9.0、v13.10.0、v13.10.1 在几周内连续发布），这意味着你需要关注这些变化。但好消息是，骨架的改动通常很小，比如配置文件调整。许可证方面，README 明确声明框架使用 MIT 许可证，因此骨架本身也是 MIT 许可，你可以自由使用和修改。但请注意，如果你修改了骨架的默认文件，这些改动可能在未来升级时产生冲突。建议使用版本控制并记录你的自定义改动。
编辑结论
laravel/laravel 适合需要快速搭建标准 PHP Web 应用的团队，尤其是那些接受 Laravel 约定、希望立即获得路由、ORM、队列和迁移能力的开发者。它不适合追求最小依赖、想完全控制目录结构的项目，也不适合已有遗留 PHP 代码库需要渐进式集成的场景。采用前应验证三点：确认你的 PHP 版本满足 13.x 的要求，检查 composer.json 中依赖的框架版本是否与你的部署环境兼容，并审阅默认的目录结构和配置项是否符合团队规范。这个骨架仓库本身不提供运行时功能，真正的行为都来自 laravel/framework 包，因此你的决策核心是选择框架，而非这个脚手架。
社区笔记