应统一用think\Model替代Db::table()、validateScene替代手写校验、think\facade\Cache替代混用缓存函数、feature.php分离配置；核心是将隐式约定转为IDE可识别、编译器可检查的硬约束。
用 think\Model 替代手动写 Db::table()
老项目里满屏 Db::table('user')->where(...)->select()，看着像 SQL 拼接，改起来怕漏字段、加关联更得查文档。新版本的 think\Model 不只是“封装一层”，它强制你把表结构、字段类型、关联逻辑都收口到类定义里。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 每个业务表建一个继承
think\Model的类，比如UserModel，在类里用protected $table = 'user'明确绑定 - 字段自动映射靠
protected $schema或注解（如@var int），避免运行时字段名拼错却无提示 - 关联方法直接写成函数，比如
public function orders()返回$this->hasMany(OrderModel::class)，调用时$user->orders就是干净的属性访问 - 别在控制器里用
Db::直连——不是不能用，而是用了就绕过模型层的验证、事件、自动时间戳等隐式契约
validateScene 代替手写 if-else 校验逻辑
提交用户注册时校验手机号格式、密码强度、昵称长度……老写法是控制器里一堆 if (strlen($data['nick']) > 20) {...}，分散、难复用、改规则要翻三四个文件。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
UserModel里定义protected $validateScene = ['register' => ['nick', 'mobile', 'password']]，再配protected $rule = [...]统一规则 - 调用时直接
(new UserModel())->validateScene('register')->save($data)，失败自动抛ValidateException，不用自己throw new Exception - 注意：场景名必须和
$rule中的键对齐；若某字段在多个场景用不同规则（如注册要唯一、编辑可跳过），得拆成'register.mobile' => 'require|mobile|unique:user'这种带前缀的写法 - 别把复杂业务逻辑塞进验证器——比如“手机号已注册”该走模型的
checkUnique方法，而不是硬塞进unique规则里
用 think\facade\Cache 统一缓存入口，别混用 Cache:: 和 cache()
项目里既有 Cache::get('user_123')，又有 cache('user_123')，看着差不多，但前者走 facade，后者是函数别名，底层行为不一致（比如 tag 支持、驱动扩展点）。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 全项目只用
think\facade\Cache，删掉所有裸cache()调用 - 缓存 key 命名加前缀，比如
user:profile:{id}，别用$id . '_profile'这种字符串拼接，避免冒号被当分隔符误判 - 设置过期时间统一用秒数，别传
3600又传1.hour()—— 后者依赖 Carbon，增加隐式依赖 - 缓存失效优先用
Cache::delete('user:profile:123')，别用Cache::clear()，后者清空整个驱动，可能误伤其他模块数据
配置分离：把 app.php 里的业务开关抽成独立 feature.php
上线后要灰度某个功能，结果发现开关散落在 app.php、database.php、甚至控制器里硬编码 if ($env === 'prod') {...}，改一次要 grep 十分钟。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 新建
config/feature.php，内容为return ['enable_new_order_flow' => env('ENABLE_NEW_ORDER_FLOW', false)] - 在环境变量里设
ENABLE_NEW_ORDER_FLOW=true，本地开发用.env，生产用服务器环境变量 - 代码里统一用
config('feature.enable_new_order_flow')，别用env('ENABLE_NEW_ORDER_FLOW')—— 后者在 config 缓存开启后会返回 null - 别把 feature 配置写进
app.php：它会被框架高频读取，而 feature 开关变更频繁，放一起会拖慢配置加载
模型层契约、验证场景、缓存入口、配置粒度——这些不是“新特性炫技”，是把模糊的“应该这么做”变成编译器能检查、IDE 能跳转、团队能对齐的硬约束。最容易被忽略的，其实是 config() 和 env() 的调用时机差异，一不小心，本地测得好好的，上生产就失效。
