在团队协作和自动化部署中，有些 Artisan 命令是绝对不希望在特定环境里被执行的，例如 migrate:fresh、db:wipe 这类会直接清空数据库的命令。Laravel 本身没有提供一个配置项让你一键关闭某些命令，但借助其启动流程中的几个扩展点，完全可以做到全局禁用。本文将从原理入手，给出几种可落地的实现方案。
一、理解 Artisan 命令的加载与执行原理
Laravel 的命令行入口是项目根目录下的 artisan 文件，它会创建一个 App\Console\Kernel 并把请求交给它处理。Kernel 内部的 commands() 方法会加载 routes/console.php 以及通过 load() 注册的命令目录，最终所有命令都会注册到 Illuminate\Console\Application 这个容器里。
当你在终端执行 php artisan list 时，Application 会把所有已注册命令的签名展示出来；执行具体命令时，它会根据签名找到对应的 Command 实例并调用其 run() 方法。这意味着，只要在命令真正执行之前把目标命令从 Application 中移除，或者在解析阶段抛出异常，就能实现禁用效果。
另一个值得关注的点是 Illuminate\Console\Application 提供了 resolve() 与 add() 等方法，命令注册本质上就是把 Symfony Command 实例塞进内部的集合。理解了这一点，下面的几种方案就很好懂了。
二、方案一：在 Console Kernel 中注销命令
最直接的做法是在 app/Console/Kernel.php 中，等命令注册完成后把危险命令注销掉。可以在 bootstrap/app.php（Laravel 11 及以后的骨架结构）中结合 withCommands 使用，也可以在旧版本中重写 Kernel 的逻辑，思路是一致的。
更优雅的做法是利用 Artisan::starting 钩子。Laravel 在 Artisan 启动时会触发这个回调，你可以在 AppServiceProvider 的 boot 方法中注册回调，在里面拿到 Application 实例后删除指定命令，代码如下。
public function boot()
{
if (! $this->app->runningInConsole()) {
return;
}
// 禁用名单，可从配置或环境变量读取
$blocked = ['migrate:fresh', 'db:wipe'];
\Illuminate\Support\Facades\Artisan::starting(
function (\Illuminate\Console\Application $artisan) use ($blocked) {
if (! $this->app->environment('production')) {
return;
}
foreach ($artisan->all() as $name => $command) {
if (in_array($name, $blocked, true)) {
// 从命令集合中注销危险命令
$artisan->remove($command);
}
}
}
);
}这种方案执行后，被禁用的命令不会再出现在 php artisan list 中，直接执行也会提示命令不存在，效果干净彻底。缺点是需要在每个 ServiceProvider 或 Kernel 中维护拦截逻辑，如果项目结构复杂，要注意只注册一次回调，避免重复遍历。
三、方案二：自定义 Application 拦截命令解析
如果希望禁用逻辑集中、可测试，可以继承 Illuminate\Console\Application，重写它的 find() 方法。当解析到被禁用的命令名时，直接抛出异常，给出明确的错误提示。
class RestrictedConsoleApplication extends \Illuminate\Console\Application
{
public const BLOCKED = [
'migrate:fresh',
'db:wipe',
];
public function find(string $name)
{
// 先让父类完成缩写解析，防止缩写绕过限制
$command = parent::find($name);
if (in_array($command->getName(), self::BLOCKED, true)) {
throw new \RuntimeException(
'命令 [' . $command->getName() . '] 已被策略禁用。'
);
}
return $command;
}
}要让 Laravel 使用这个自定义类，需要替换容器中 artisan 的绑定实例。在 AppServiceProvider 的 register 方法中重新绑定单例即可完成替换。这种方案的优点是拦截点非常靠前，即使第三方包注册了同名命令也会被拦下，适合对安全性要求较高的场景。
需要特别注意，Symfony 的 find() 支持命令缩写，例如输入 migrate:f 时框架可能自动补全成 migrate:fresh。因此做匹配时应先调用父类方法拿到完整命令对象，再基于 getName() 判断，避免缩写绕过限制。
四、方案三：事件监听与入口脚本包装
除了在加载阶段处理，还可以利用命令生命周期事件。Illuminate\Console\Events\CommandStarting 事件在每条命令执行前触发，监听器中可以拿到命令名和输入输出对象，命中黑名单时直接抛出异常终止执行。这种方式代码侵入小，适合只想针对个别命令做软性限制的团队。
// app/Providers/EventServiceProvider.php 中注册监听器
protected $listen = [
\Illuminate\Console\Events\CommandStarting::class => [
\App\Listeners\BlockDangerousCommands::class,
],
];
// app/Listeners/BlockDangerousCommands.php
class BlockDangerousCommands
{
public function handle($event)
{
$blocked = config('artisan.blocked', []);
if (in_array($event->command, $blocked, true)) {
throw new \RuntimeException(
'命令 [' . $event->command . '] 已被禁用。'
);
}
}
}还可以从运维层面做一层包装。写一个包装脚本替换原始的 artisan 入口，先解析用户输入的命令名，命中黑名单就拒绝执行。这种方案与框架版本解耦，升级 Laravel 时不容易被破坏，而且可以配合 CI/CD 流水线统一管控。缺点是只覆盖通过该入口调用的场景，如果有人通过队列任务或调度器间接执行命令，则拦截不到。
五、环境隔离与权限控制的补充实践
很多团队禁用命令的真实诉求是生产环境只读。除了黑名单，还可以从数据库账号权限入手：给生产环境的应用使用只有 SELECT、INSERT、UPDATE、DELETE 权限的数据库账号，迁移操作使用另一个高权限账号在审批流程中手动执行。这是最根本的兜底手段，任何框架层的禁用都可能被绕过，但数据库权限不会说谎。
再配合环境变量做开关，可以让同一套代码在不同环境表现不同。例如在 .env 中定义 ARTISAN_BLOCKED=migrate:fresh,db:wipe，代码中通过 config() 或 env() 读取并解析成数组，运维人员只需调整配置就能更新禁用列表，无需改动代码重新发布。
最后建议把禁用策略记录在部署文档中，并在命令被拦截时输出清晰的提示信息，告诉团队成员应该走什么流程来完成任务。技术上的限制加上流程上的引导，才能真正避免误操作带来的线上事故。
总结
全局禁用 Artisan 命令可以从多个层面入手：在 ServiceProvider 中通过 Artisan::starting 回调注销命令、自定义 Console Application 重写解析逻辑、利用 CommandStarting 事件做软拦截，或者通过包装脚本在运维层管控，再配合数据库权限做最底层的兜底。选择哪种方案取决于你的安全等级要求与团队协作方式，通常将环境变量驱动的黑名单与数据库权限控制组合使用，能兼顾灵活性与安全性。