接手这个项目的时候，我第一反应是有点意外：ThinkPHP 和 Laravel 这两个框架，平时大家总是习惯二选一，怎么会在同一个项目里出现？仔细一看需求才明白，这不是技术选型出了问题，而是这个儿童性教育网站本身就有天然的分工需求——新闻资讯、文章库、论坛社区，三个模块对开发效率、数据一致性、生态成熟度的要求完全不一样，用两套框架各管一段，反而是更务实的做法。
这个项目的核心定位很清晰：面向儿童和青少年的性教育内容平台，既要承载专业、严谨的科普文章和新闻资讯，又要提供一个让家长、老师、孩子之间能安全交流的论坛社区。这类网站最大的特点就是“内容敏感、用户特殊、审核要求极高”，所以技术方案不能只考虑“能不能跑起来”，还要考虑“怎么跑得稳、怎么防得住、怎么好维护”。
作为一个从 PHP 5.2 时代就开始写业务的老家伙，我对这套组合方案的落地过程还是挺有感触的。这篇就把整个项目的设计思路、核心模块实现、还有几个绕不开的技术细节完整拆一遍，尤其是 Laravel 里 groupBy + orderBy 取最新一条去重这种高频需求，以及 ThinkPHP 里 input('/d') 参数过滤和 ext-json 扩展这些坑，都会结合实测经验讲透。
1. 项目整体设计与技术选型解析
1.1 为什么是 ThinkPHP + Laravel 双框架，而不是二选一
先说说这个项目为什么会同时用两套框架。很多人一听“一个项目两个框架”就觉得是过度设计，但实际上这套方案是业务倒逼出来的，不是炫技。
儿童性教育网站的内容分成两大块：第一块是新闻和文章，这类内容的特点是结构固定、访问量大、对 SEO 要求高、后台管理频率高；第二块是论坛社区，这类内容的特点是交互复杂、实时性要求高、用户权限逻辑繁琐、还需要做敏感词过滤和审核流。把这两块塞进同一个框架不是不行，但开发效率和后期维护的灵活性会打折扣。
ThinkPHP 的优势在于上手快、文档中文友好、ActiveRecord 模式写 CRUD 非常直接，特别适合后台管理这类“重表单、重列表、重流程”的场景。Laravel 的优势在于生态成熟、Eloquent ORM 强大、队列和事件机制完善，适合论坛这种“重交互、重异步、重扩展”的场景。所以我当时定的方案是：后台管理和新闻发布用 ThinkPHP，前台社区和用户交互用 Laravel，两个应用共用同一个数据库，通过 API 或直接共用数据表完成数据交换。
实际开发中，这个方案最大的收益是团队协作效率。负责后台的人不用被 Laravel 的路由和中间件复杂度困扰，负责社区的人不用被 TP 的模板引擎限制表达。而且两个框架都是 PHP，部署在同一套 PHP-FPM 环境下，运维成本没有明显增加。
1.2 模块边界划分与数据共享方案
两个框架跑在一个项目里，最怕的是边界不清。我这里定了一个原则：按业务域划分，不按技术栈划分。
- ThinkPHP 负责：后台管理（文章发布、新闻审核、用户管理、数据统计）、内容管理后台的所有 CRUD 操作。
- Laravel 负责：前台展示（文章列表、新闻详情）、论坛社区（发帖、回帖、点赞、关注）、用户注册登录、个人中心。
数据库共用一套，但两边的表设计有明确约定。比如文章表articles的status字段，ThinkPHP 后台写入1（已发布）、0（草稿）、2（审核中），Laravel 前台只查询status = 1的数据。这种约定看起来简单，实际避免了双框架下最头疼的“数据口径不一致”问题。
数据共享还有一个细节：自增主键和软删除字段要统一。比如论坛的posts表，Laravel 默认用id做主键，附带deleted_at做软删除，ThinkPHP 那边如果不了解这个约定，写 join 查询时就会漏掉软删除条件，导致后台统计数字和前台实际数据对不上。这个坑我后面会细说。
2. 儿童性教育网站的特殊需求与功能设计
2.1 内容安全与适龄保护机制怎么落地
这类网站跟普通资讯站最大的区别，就是内容安全不能只靠“事后删帖”。儿童性教育的内容一旦出问题，影响的是孩子和家长对平台的信任，甚至是法律风险。所以项目从第一天起就把内容安全机制放在最高优先级。
具体做了三件事：第一，敏感词过滤前置。在文章发布和论坛发帖的时候，除了后台关键词库的实时过滤，还接入了第三方的文本审核接口，图片也会做涉黄涉暴识别。这里要注意，接口审核是异步的，不能阻塞用户发布，所以用了 Laravel 的队列把审核任务丢到 Redis 里异步处理，用户提交后先显示“内容审核中”，审核通过后再公开可见。第二，适龄内容分级。文章和帖子都增加了一个grade字段，分为 0-6 岁、7-12 岁、13-18 岁三个级别，前台根据用户的年龄设置展示对应内容。这个设计在性教育网站里特别关键，因为不同年龄段孩子能接受的信息确实差别很大。第三，举报和人工复审通道。每个内容页面都有举报入口，举报记录进数据库后，后台管理端会高亮提醒，管理员复审后可以下架或封禁。
这套机制看起来不复杂，但落地时有一些细节很耗功夫。比如敏感词过滤用的是什么算法、怎么避免误伤“阴茎”“阴道”这类本身就属于性教育内容的专业词汇；再比如图片审核怎么处理手绘插图，因为儿童性教育内容里大量使用卡通插图，AI 识别经常误报。后面我会把这些问题放进“常见问题”章节里专门讲。
2.2 新闻与文章模块：结构化内容管理设计
新闻和文章模块是整个网站的内容基石，承载的是专业教育机构、心理专家、一线教师写的科普内容。这类内容有几个特点：篇幅长、图文混排、有专业术语、可能需要标注参考文献和适用年龄段。
所以在内容表设计上，除了常规的title、content、author_id、status、published_at之外，还加了几个字段：summary（摘要，列表页展示用）、cover_image（封面图）、grade_range（适龄范围）、source_type（内容来源，区分原创、转载、专家投稿）、view_count（浏览量，用于热门排序）。
这里我特别想说的是摘要字段的重要性。很多开发者在做文章系统时会忽略摘要，列表页直接截取正文前 100 个字。但对于儿童性教育这种相对严肃的内容，截取正文非常容易把句子拦腰截断，比如“性教育不是教孩子...”截成“性教育不是教孩”，既影响阅读体验，又显得不专业。所以文章发布后台把摘要做成必填项，发布编辑时必须手动填写，字数限制在 80-120 字之间。
新闻模块和文章模块在技术实现上基本一样，主要区别是新闻的时效性强，列表页要按published_at倒序，并且有一个“重大新闻”置顶的 toggle 开关。文章模块则更强调专题聚合，比如“青春期心理”“自我保护”“性别平等”这些专题，通过category_id和tags字段实现多维度筛选。
2.3 论坛模块：防滥用与家长管控设计
论坛是这类网站里最容易出问题的部分，因为它是 UGC（用户生成内容），不可控因素最多。儿童性教育论坛的用户群体比较复杂——有来提问的青少年、有学习交流的家长、有分享经验的老师，还有少数目的不纯的注册者。所以论坛模块的设计核心是“控制”而非“开放”。
第一层控制是发帖权限。新注册用户 24 小时内不能发帖，只能浏览和点赞，这个限制能挡住大部分注册后立刻发垃圾内容的机器人。第二层控制是内容审核。所有新帖子和新回复先进入“待审核”状态，管理员审核通过后才公开展示。这个规则对用户体验有一定影响，但考虑到网站的性质，必须先保证安全再谈体验。第三层控制是敏感行为监控。同一 IP 频繁发帖、短时间内大量回复、被举报超过 3 次，系统会自动冻结账号，需要管理员手动解封。
家长管控方面，做了一个“家长模式”功能。家长注册后可以绑定孩子的账号，绑定后能查看孩子的发帖和回复记录，也能设置孩子的发帖权限（比如只能发提问帖，不能发评论）。这个功能在隐私保护上需要做好权衡——既要让家长有监管能力，又不能完全公开孩子的所有行为，所以我们做了一个折中方案：家长只能看到孩子发的内容，不能看到孩子给谁点的赞、收藏了什么，这样既满足了监管需求，也保留了一定的个人空间。
3. 核心功能实操：从用户体系到内容发布
3.1 双框架下的用户认证与权限控制
这个项目里最需要设计好的一环就是用户认证。因为两套框架共用数据库，用户在 Laravel 前台注册的账号，必须能在 ThinkPHP 后台被识别和处理；后台管理员创建的账号，也必须能在前台正常登录。如果两边各自的 session 机制不一致，就会出现“后台登录了，前台还提示未登录”这种尴尬情况。
我的方案是：统一认证基于数据库，不做框架间的 session 共享。用户表users使用 Laravel 的默认结构（注意是 Laravel 8 之后默认的users表结构，密码字段是password，不是 TP 习惯的pwd），注册、登录全部在 Laravel 这边处理。ThinkPHP 后台要判断用户身份时，直接查询users表和user_roles表——管理员也是一个用户，只是role_id字段值不同。
这样做的好处是逻辑简单、不容易出 bug。缺点是多了一次数据库查询，但对这个量级的网站来说，性能影响可以忽略。真正的挑战是密码加密方式的兼容。Laravel 默认用Hash::make()生成的密码是 bcrypt 加密，ThinkPHP 里没有现成的 bcrypt 验证函数，需要引入password_verify()这个 PHP 内置函数来验证。代码大概长这样：
// ThinkPHP 后台管理员登录验证 public function login() { $username = input('post.username'); $password = input('post.password'); $admin = Db::name('users') ->where('username', $username) ->where('role_id', 1) ->find(); if ($admin && password_verify($password, $admin['password'])) { session('admin_id', $admin['id']); return json(['code' => 1, 'msg' => '登录成功']); } return json(['code' => 0, 'msg' => '账号或密码错误']); }注意这里有个细节：password_verify()验证 bcrypt 哈希时不需要任何额外参数，PHP 7+ 自带支持。但要让password_verify()能用，PHP 环境必须安装了sodium扩展或使用 PHP 内置的 password 函数，实际上 PHP 5.5+ 就内置了，这也就规避了 ext-json 之外另一个容易被忽略的扩展依赖问题。
3.2 文章发布与审核流程的实现细节
文章发布流程是这样设计的：编辑在 ThinkPHP 后台新建文章 → 填写标题、摘要、正文、封面图、分类、适龄范围等字段 → 提交后状态为“待审核” → 审核员在后台查看文章详情 → 通过则状态改为“已发布”，不通过则填写驳回原因 → 前端 Laravel 查询已发布文章展示。
这里的核心难点在于，ThinkPHP 写入了文章数据，Laravel 端要能立刻读到。因为共用的是同一个数据库，所以不需要做什么同步操作，只要 Laravel 的查询条件过滤掉非发布状态即可。但有一个问题：两套框架的时间格式化方式不一样。ThinkPHP 默认的create_time是datetime类型，而 Laravel 的 Eloquent 默认期望created_at是timestamp类型。虽然是同一个字段，但两边读出来的格式会有细微差异，导致前台显示时间不对。
我的解决办法是在 Laravel 的 Article 模型里显式定义时间字段格式：
<?php namespace App\Models; use Illuminate\Database\Eloquent\Model; class Article extends Model { protected $table = 'articles'; const CREATED_AT = 'create_time'; const UPDATED_AT = 'update_time'; protected $casts = [ 'create_time' => 'datetime:Y-m-d', ]; }这样 Laravel 读出来的create_time就是格式化好的日期字符串，跟前台展示的需求刚好对上。这个模型字段映射的细节，在双框架共用数据库的场景里非常关键，几乎每个表都要检查一遍。
3.3 论坛热帖与最新回复列表的实现
论坛首页的常见布局是：左侧最新帖子、中间热门推荐、右侧最新回复。这三个板块的数据查询逻辑各有不同，其中“最新回复”这个需求最典型也最容易写错。
需求是这样的：要展示最近有回复的帖子列表，但每个帖子只显示一条记录，并且要取该帖子最后一条回复的作者和时间。这个需求如果用最直观的写法，很容易写成先按回复时间排序、再 groupBy 去重，结果发现取到的不是最新的那条回复——这正是用户热词里 Laravel groupBy + orderBy 取最新一条的核心痛点。
我先把正确的 SQL 写出来：
SELECT p.*, r.last_reply_at, r.last_reply_user FROM posts p LEFT JOIN ( SELECT post_id, MAX(created_at) AS last_reply_at FROM replies GROUP BY post_id ) r ON r.post_id = p.id WHERE p.status = 1 ORDER BY r.last_reply_at DESC LIMIT 10思路是先对replies表做一个子查询，按post_id分组，用MAX(created_at)取出每个帖子最近一条回复的时间，然后主查询 join 这个子查询结果，按最新回复时间排序。为什么不能直接GROUP BY post_id然后ORDER BY created_at DESC？因为 SQL 标准里，GROUP BY之后 SELECT 的字段必须是分组字段或聚合函数，你要是直接SELECT *然后再ORDER BY created_at，MySQL 在ONLY_FULL_GROUP_BY模式下直接报错，即使没开这个模式，取到的created_at也不保证是组内的最大值。
这只是第一步。如果还要把那条最新回复的具体内容也带出来，就得用更精细的子查询：
SELECT r.* FROM replies r INNER JOIN ( SELECT post_id, MAX(created_at) AS max_created_at FROM replies GROUP BY post_id ) rm ON r.post_id = rm.post_id AND r.created_at = rm.max_created_at这个查询能拿到每个帖子最新的一条回复，但有一个隐患：如果同一帖子有两三条回复的时间完全相同（比如秒级精度下并发插入），就会返回多行。所以实际项目里我在replies表加了自增主键id，改成用MAX(id)代替MAX(created_at)来定位最新回复，因为自增 id 是绝对唯一的，不会出现时间相同导致的歧义。
SELECT r.* FROM replies r INNER JOIN ( SELECT post_id, MAX(id) AS max_id FROM replies GROUP BY post_id ) rm ON r.id = rm.max_id这个写法也是 Laravel 里处理这类需求时最常见的优化方式。用 Query Builder 来表达：
$latestReplies = DB::table('replies') ->join(DB::raw('(SELECT post_id, MAX(id) AS max_id FROM replies GROUP BY post_id) rm'), function ($join) { $join->on('replies.id', '=', 'rm.max_id'); }) ->join('posts', 'posts.id', '=', 'replies.post_id') ->where('posts.status', 1) ->orderBy('replies.created_at', 'desc') ->limit(10) ->get();这样写，社区首页“最新回复”板块不仅能展示帖子标题，还能展示最新回复人的昵称和回复时间，配合缓存层几乎不会有性能问题。
4. 几个绕不开的技术细节：input('/d')、groupBy 去重、ext-json
4.1 ThinkPHP 的 input('/d') 到底做了什么
热词里有“thinkphp input /d”，看起来是个很冷门的写法，实际在项目里用得非常频繁。它的作用是强制将输入值转换为整型。比如input('id/d')，如果传入的id是字符串'abc'，经过/d过滤后会变成0；如果传入的是'12'，会变成整数12。
为什么要这么做？因为很多 SQL 注入和越权漏洞，根源就是开发者直接把用户输入拼进查询条件。比如后台要删除一篇文章，URL 是/admin/article/delete?id=5，如果直接用$id = input('id')，然后拼进 where 条件，攻击者可能把id改成5 OR 1=1，导致删掉全表。加上/d之后，input('id/d')得到的一定是整型，如果是非法字符串，结果是 0，查询不到任何数据，安全风险直接归零。
实战中我建议所有从 URL 参数和表单获取的 ID 类字段，一律用/d过滤：
// 不安全的写法 $id = input('id'); $article = Db::name('article')->where('id', $id)->find(); // 安全的写法 $id = input('id/d'); $article = Db::name('article')->where('id', $id)->find();另外/d的应用场景还包括分页参数input('page/d')、排序参数input('sort/d')，这些参数如果不强制整型，轻则报错重则埋雷。除了/d，ThinkPHP 还支持/s（强制字符串）、/f（强制浮点型）等过滤规则，但不推荐过度使用——比如用户名的处理还是应该用字符串，不能用/d把用户名强制转成 0。
4.2 Laravel 用 groupBy + orderBy 取最新一条的正确姿势
这是 Laravel 开发中被问得最多的 SQL 问题之一。很多新手写这样的代码：
// 错误的写法 DB::table('replies') ->groupBy('post_id') ->orderBy('created_at', 'desc') ->get();这段代码的执行结果跟预期完全不搭。原因我在前面 SQL 分析时已经讲过了：GROUP BY之后，ORDER BY排序的不是组内每行的数据，而是分组结果。在 MySQL 的ONLY_FULL_GROUP_BY模式下直接报 SQL 错误，在不严格模式下，created_at取的可能是组内任意一条记录的 create_time，根本没法保证是最新的一条。
正确的姿势有两个：
方法一：子查询 + MAX(id)。这个已经在论坛列表实现里写过，核心思路就是先查每个分组里 id 最大的那一条，再回表取完整数据。优点是兼容所有 MySQL 版本，缺点是子查询在数据量大时会稍微慢一点，配合索引就没有问题。
方法二：窗口函数（MySQL 8.0+）。如果你用的是 MySQL 8.0 及以上版本，窗口函数ROW_NUMBER()是更优雅的解决方案：
SELECT * FROM ( SELECT r.*, ROW_NUMBER() OVER (PARTITION BY post_id ORDER BY id DESC) AS rn FROM replies r ) t WHERE t.rn = 1这个写法先按post_id分区，每个分区内按id倒序排号，然后取每组第一行（rn = 1），语义上非常清晰。Laravel 里可以用DB::raw()包裹这段 SQL，或者在模型里使用whereIn配合子查询。MySQL 5.7 及以下没有窗口函数，只能用方法一。
我认为在实际项目中，方法一仍然是最稳妥的选择，因为很多部署环境还没升级到 MySQL 8.0，而且方法一通过post_id上的复合索引(post_id, id)可以做到非常高效的查询。
4.3 ThinkPHP 安装 ext-json 扩展的完整经过
热词里有“thinkphp 安装 ext-json”，这是一个非常典型的部署环境问题。ThinkPHP 从 6.0 开始，官方对 PHP 扩展有明确要求，ext-json是必须安装的基础扩展之一。如果你的服务器 PHP 环境没装 json 扩展，ThinkPHP 会直接抛出一个致命错误：“缺少 json 扩展”。
为什么 TP6 强制要求 json 扩展？因为 TP6 的很多核心功能都依赖 JSON 数据格式，包括：json()函数返回 JSON 响应、Session 驱动的序列化存储、数据库 JSON 字段的处理、API 返回格式封装等。没有 json 扩展，整个框架几乎跑不起来。
解决办法分系统环境来说：
Ubuntu / Debian 系统（PHP 7.x）：
sudo apt-get install php7.4-json sudo service php7.4-fpm restartCentOS / RedHat 系统（PHP 7.x）：
sudo yum install php-json sudo systemctl restart php-fpm注意，如果你用的是 PHP 8.0 及以上版本，json 扩展已经默认内置且无法移除，不需要再单独安装。这一点很容易误导人——有些旧教程还在教你怎么装 php-json，但在 PHP 8 环境下根本不生效。
我这里踩过一个坑：在 Ubuntu 上用apt list --installed | grep json查看，以为装了 json 扩展，结果发现装的是php-json这个元包，实际生效的是php8.1-json自带的 JSON 支持。所以正确的检查方法不是看包名，而是跑一下：
php -m | grep json如果能看到json，说明扩展已经加载。如果看不到，才需要按照上面命令安装扩展包。
此外，如果你用的是 PHP 7.2+，官方已经建议使用 JSON 扩展作为 PHP 核心的一部分，默认就开启，不需要额外安装。真正容易出问题的是那些从 PHP 5.6 升级上来的老环境，或者用宝塔面板但没在 PHP 扩展管理里勾选 json 的情况。
5. 常见问题与排查技巧实录
5.1 双框架 session 失效和登录状态不同步
这个项目前期出现最多的一个问题是：用户在前台 Laravel 登录成功了，但是跳转到后台 ThinkPHP 管理的页面时，后台仍然显示未登录；反过来也是一样。排查来排查去，发现是 session 名称冲突。
ThinkPHP 默认的 session 名称是PHPSESSID，Laravel 默认的 session 名称是laravel_session，两个框架在同一个域名下分别生成了不同的 session cookie。从用户角度看，如果在 Laravel 登录了，浏览器会存一个叫laravel_session的 cookie；访问 ThinkPHP 后台时，PHP 去找的是PHPSESSID这个 cookie，自然找不到登录状态。
解决方案是让两个框架各自使用不同的 session key 和 cookie 名称，避免相互覆盖；同时，后端通过users表统一认证，实际上不需要依赖前台的 session。具体配置是：
// ThinkPHP config/session.php 'session_name' => 'tp_admin_session', // Laravel config/session.php 'cookie' => 'laravel_session',由于这个项目是按业务域划分框架的，后台和前台实际是分开访问的，所以 session 不同步其实不影响认证逻辑——后台管理员通过users表手动查询验证，前台用户通过 Laravel 的 auth 中间件验证。两个系统唯一的交集是数据库，只要两边都不把登录状态写入对方的 session，就不会出问题。
5.2 内容审核误伤专业术语，怎么优化敏感词库
调试阶段遇到的另一个高频问题是，内容审核把很多正常的性教育专业术语标记成了敏感词。比如“性行为”“避孕”“性传播疾病”这些词，本身是青少年性教育里必须科普的内容，但通用的敏感词库会直接把它们拦截。
这个问题的根源在于：通用敏感词库是为“过滤不当内容”设计的，而我们需要的是“允许合法科普、过滤恶意内容”。两者的边界完全不同。我的解决思路是建立一份“白名单词库”。具体做法是：管理员在后台维护一个白名单词汇表，只有后台审核员和专家用户发布的文章可以命中白名单，普通用户发帖时仍然执行严格过滤。同时，对普通用户在论坛发帖时涉及敏感词的，不直接拦截，而是提示“内容包含敏感信息，已进入人工审核”——这样既保证了专业内容可以正常发布，又防止了普通用户打擦边球。
还有一个细节容易被忽略：内容审核不能只看关键词，还要看上下文。比如“孩子被摸了”这句话里的“摸”是中性词，但如果出现在“摸大腿”这类语境里，性质就完全不同。纯关键词匹配无法解决这个问题，只能依靠人工复审。所以实际流程是：机器先过滤掉明显违规内容，剩下的疑点内容全部进入人工审核队列，宁可多人工审核，也不能错放一条。
5.3 性能优化：列表页慢查询的排查过程
网站上线一段时间后，用户反馈论坛首页打开变慢。我测试了一下，首屏加载要 4 秒，明显不正常。通过EXPLAIN查看 SQL 执行计划，发现慢查询出在论坛列表页的那条“最新回复”子查询上。
原因很简单：replies表的数据量已经超过 10 万条，子查询里的GROUP BY post_id虽然用了post_id索引，但MAX(id)的聚合操作要扫描整个分组，加上外层又要 joinposts表，查询成本成倍增加。
优化的思路有两个方向。第一，给replies表加一个复合索引：
ALTER TABLE replies ADD INDEX idx_post_id_id (post_id, id);这个索引能让GROUP BY post_id和MAX(id)的聚合操作都走索引，无需回表。加了之后 EXPLAIN 的结果显示查询类型从ALL（全表扫描）变成了INDEX（索引扫描），耗时从原来的 2.3 秒降到 0.1 秒。
第二，也是更关键的一步：加缓存。因为论坛首页的“最新回复”板块对实时性要求没那么高，10 分钟更新一次完全没有问题。我用 Laravel 自带的 Cache 门面做了一个简单的缓存：
$latestReplies = Cache::remember('forum_latest_replies', 600, function () { return DB::table('replies') ->join(...) ->orderBy('replies.created_at', 'desc') ->limit(10) ->get(); });10 分钟过期时间，过期后自动重新查询并写入缓存。这样即使数据库查询再慢，用户每次访问时也是直接读缓存，响应时间从 4 秒直接降到 300 毫秒以内。
这里我建议大家在开发这类内容站点时，先想清楚数据量级再决定是否用缓存。如果数据量只有几千条，加索引就够了；但一旦超过几万条，缓存几乎是必须的。
6. 个人经验总结与扩展建议
项目上线后我仔细复盘过这套双框架方案，最大的感受是：技术没有绝对的对错，只有适不适合。ThinkPHP 和 Laravel 的组合看起来不传统，但在这个儿童性教育网站上确实是把各自的优势发挥到了最大——后台管理的高效率和前台社区的强生态，彼此互补，没有明显的内耗。
如果你也想参考这个方案，我的建议是注意三点：第一，两套框架的边界一定要清楚，建议在项目文档里明确写清楚“哪张表归谁写、哪个字段归谁读”，避免后面接手的人乱搞；第二，数据库表设计要兼顾两边的习惯，比如时间字段、软删除字段、状态字段这类公共约定，必须提前定好；第三，内容安全机制要从第一天就设计进去，不要等上线了再补，因为这类网站一旦出现安全问题，代价远超普通项目。
后面这个项目还可以扩展的方向其实不少：比如基于用户年龄段做个性化内容推荐、接入微信公众号推文、增加专家在线问答功能等等。从技术角度看，现有架构完全能支撑这些扩展——Laravel 这边的队列和事件机制已经跑起来了，ThinkPHP 后台的权限管理也已经预留了扩展点。我自己的体会是，把一个儿童教育相关的网站做好，技术只是基础，更重要的是产品对内容安全、对用户体验、对教育本身的理解。技术方案选得好，只是让这些理解能顺利落地而已。
