字段冗余本质是职责错位：模型字段规则塞进控制器、配置参数散落多文件、关联字段依赖人肉记忆；应统一收口至模型$allowfield、闭包内field()限制关联字段、独立config.inc.php合并配置、composer精简依赖。
ThinkPHP 里字段冗余不是“多写了几个字段”，而是模型定义、查询语句、控制器逻辑三者之间没对齐，导致同一个字段在多个地方重复声明、过滤或校验——最终查出来一堆用不上的数据，还容易漏掉关键外键。
模型 $allowField 静态属性 vs 控制器 allowField() 调用
控制器里每次 save() 前手动写 $model->allowField(['name', 'email'])，等于把字段白名单硬编码进业务动作；改个接口就得翻三四个文件。这不是灵活，是失控。
- 统一收口到模型层：
protected $allowField = ['name', 'email', 'status']，一劳永逸 - 但注意：如果某些接口要动态控制（比如后台全字段、前端只允许改头像），就别用静态
$allowField，改用基类控制器里的getAllowFields()方法，按$this->request->action()返回不同数组 -
$allowField不影响数据库结构，只限制 ORM 写入字段；它和数据库的NOT NULL、默认值无关，别指望它替代数据库约束
关联预加载字段限制必须写在 with() 闭包里
with('user')->field('id,nickname') 完全无效，字段限制只作用于主表；真正生效的写法是 with(['user' => function($q) { $q->field('id,user_id,nickname,avatar'); }])。
- 必须包含外键（如
user_id）和关联模型主键（如id），否则toArray()里关联数据为空——这是最常踩的坑 - TP6.0.13+ 支持闭包内
field()，老版本会静默忽略，升级前先测 - 字段名冲突时加别名：
->field('user.id as user_id, nickname')，TP 不会自动加前缀
配置文件合并：用独立 config.inc.php 替代多处重复 DB 配置
前后台 config.php 里都写一遍 'DB_HOST' => 'localhost'，等于埋了个运维雷——换库时漏改一个，线上直接报错。
- 在项目根目录建
config.inc.php，return ['DB_TYPE' => 'mysql', 'DB_NAME' => 'demo', ...]; - 各环境配置文件里统一用：
$arr02 = include './config.inc.php'; return array_merge($arr01, $arr02); - 别把敏感配置（如密码）直接写死在
config.inc.php，应改用.env+Env::get('DB_PASSWORD')，避免提交到 Git
Vendor 目录臃肿：用 composer depends 定位并移除非必要依赖
装个 monolog/monolog 却拉下整个 symfony/console，不是 Composer 太贪，是你没锁版本也没清理依赖树。
- 查谁拖了累赘：
composer depends symfony/console，看是不是真被 TP 或你的代码调用 - 锁定精简版本：
composer require guzzlehttp/guzzle:7.5.1，避免 v7.9+ 新增的 PSR-18 流式支持等冗余特性 - 生产部署前执行：
composer install --no-dev --optimize-autoloader，删掉require-dev包并生成优化类映射
字段冗余的本质是职责错位：该由模型管的字段规则，塞进了控制器；该由配置驱动的连接参数，散落在多个 PHP 文件里；该按需加载的关联字段，却靠人肉记忆去写闭包。越往后维护，越容易在“看起来差不多”的地方栽跟头。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
