FastAdmin二次开发是当前最省力、最可控的选择——尤其适合需字段自定义、审核流、ERP对接等真实业务需求，因其基于ThinkPHP 5.1且具备成熟插件机制、权限体系与代码生成能力。
ThinkPHP 开发 CMS 系统不是“搭个框架就能用”，而是得明确：你要的 CMS 是轻量级内容展示，还是企业级可扩展后台？答案不同，路径完全不同。直接上结论：用 ThinkPHP 6.x 从零写基础 CMS 可行但费时；用 FastAdmin（基于 ThinkPHP 5.1）二次开发是当前最省力、最可控的选择——尤其当你需要字段自定义、审核流、ERP对接等真实业务需求。
ThinkPHP 6.x 从零建 CMS 的典型卡点
- 路由配置稍不注意就导致
admin/和index/模块冲突，比如Route::get('article/:id', 'Index/Article/read')和后台同名路由同时存在时，没加domain或group隔离，请求直接进错模块 - 模型关联写法在 6.x 中默认启用严格模式，
with(['category', 'tags'])查询时若category关联模型未定义pk或foreignKey，会静默返回空数组而非报错，调试半天才发现是模型里漏写了protected $pk = 'id'; - 分页对象返回的是
think\Paginator实例，但模板里直接{$list->render()}会报错，必须确认是否启用了template配置里的layout，且分页模板路径是否正确（默认找view/common/paginate.html） -
validate验证器在控制器中调用$this->validate($data, 'rule')时，若 rule 是字符串（如'ArticleValidate'），类必须放在app\validate\下且命名空间匹配，否则抛出ClassNotFoundException
FastAdmin 二次开发时绕不开的三处硬配置
FastAdmin 不是黑盒，它的可定制性恰恰藏在几个关键配置文件里：
-
application/extra/admin.php控制后台菜单、权限节点和插件开关，修改后必须清空runtime/cache/下的缓存，否则新菜单不显示 -
application/common/model/Category.php是分类模型的基类，若你要支持多级无限分类，必须重写tree()方法并确保数据库字段含pid和level，不能只依赖前端 JS 拼树 -
public/assets/js/require-backend.js定义了所有后台 JS 模块加载规则，新增一个自定义控制器Product后，必须在这里加一行'product': 'backend/product'，否则点击菜单提示 “Module not found”
自定义内容模型时最容易被忽略的数据库约束
客户说“加个产品页，要支持规格参数和多图”，你建了 fa_product 表，但上线后上传图片失败或搜索失效，大概率栽在这几条：
-
fa_product表主键必须是id（INT类型），不能用uuid或varchar，否则 FastAdmin 的 CRUD 基类方法（如getRelationData）会因类型不匹配跳过关联查询 - 多图字段（如
images）必须设为TEXT类型，并在模型里显式声明protected $type = ['images' => 'json'];，否则自动写入时被当成字符串截断 - 若需按规格搜索，不要把规格存成 JSON 字段后靠 PHP 解析过滤，而应拆出独立表
fa_product_spec，用标准 JOIN 查询，否则 MySQL 无法走索引，万级数据时列表页直接超时
FastAdmin 的 builder 类生成的增删改查页面看着省事，但它不会帮你决定字段要不要进搜索条件、要不要参与权限校验、是否允许导出。这些逻辑一旦漏掉，上线后就是生产事故——不是功能不能用，而是“能用，但用错了”。
立即学习“PHP免费学习笔记（深入）”；
