服务容器不区分环境，但具体实例需按环境差异化注册；env()不可在register()中直接使用，应改用App::environment()或config()；多环境服务应显式命名或boot阶段绑定；数据库需定义多连接而非依赖APP_ENV。
服务容器本身不区分环境，但绑定到容器里的具体实例（比如数据库连接、日志通道、HTTP客户端）必须按环境差异化注册——否则本地能跑，上线就报错。
env() 不能直接用在 service provider 的 register() 里
很多开发者在 AppServiceProvider::register() 中直接写 if (env('APP_ENV') === 'local')，结果生产环境永远进不去分支。因为 env() 在配置缓存后返回 null，而 register() 阶段配置早已加载完毕。
- 正确做法：先在
config/app.php或自定义配置文件中用env('APP_ENV', 'production')解析出环境标识，再用config('app.env')判断 - 更稳妥的是用
App::environment(['local', 'staging'])，它不依赖env()，只读取已解析好的环境值 - 避免在
register()中做任何需要实时读取.env的逻辑，比如动态 require 配置文件
多环境绑定服务时，别复用同一个 binding key
比如你为本地和生产分别注册了不同的 HTTP 客户端实例，但都 bind 到 HttpClient::class，Laravel 不会自动覆盖或切换——后注册的会完全替换前一个，且无警告。
- 推荐显式命名：用
bind('http.client.local')和bind('http.client.production')，再通过条件判断 bind 主键 - 或者统一 bind 到
HttpClient::class，但在boot()阶段根据环境 set 实例：$this->app->instance(HttpClient::class, $client) - 如果用了
singleton()，注意它只在第一次 resolve 时执行闭包，后续调用不会重跑逻辑，所以闭包内必须包含完整的环境判断
数据库连接不是“多环境”，而是“多连接”——别混淆概念
很多人以为把 APP_ENV=production 就能自动切到另一个库，其实 Laravel 的 DB_CONNECTION 只控制默认连接名，跟环境变量是两套机制。要连多个库，得先在 config/database.php 的 connections 数组里注册新连接（如 mysql_analytics），再确保 .env 里有对应前缀的变量（如 DB_ANALYTICS_HOST）。
- 模型里用
protected $connection = 'mysql_analytics';是最轻量的绑定方式 - 运行时切换：
DB::connection('mysql_analytics')->table(...) - 改完
.env后必须运行php artisan config:clear，否则新变量不会注入到config/database.php中 - 别在
.env里共用DB_HOST，否则所有连接都会被它覆盖；每个库必须用独立前缀，比如DB_MAIN_HOST/DB_LOGS_HOST
真正容易被忽略的点是：服务容器的 binding 时机早于配置加载完成，所以任何依赖 env() 的逻辑都得往后挪到 boot()，或者转成配置驱动。硬编码判断环境再注册服务，迟早会在缓存配置后失效。
