应存 MySQL 而非文件系统，因其支持 SELECT、WHERE、ORDER BY 等结构化查询；建表需含 id、post_id、author_name、content、created_at、status 等字段，并做服务端校验、XSS 转义、防刷及 AJAX 提交优化。
评论数据该存 MySQL 还是文件系统？
绝大多数 PHP 动态网站用 MySQL 存评论，不是因为“高级”，而是因为 SELECT、WHERE、ORDER BY created_at DESC 这类操作天然需要结构化查询能力。用文件存（比如 JSON 写入 comments.json）在 10 条以内能跑通，但一旦开启分页、按文章 ID 筛选、防重复提交，就会卡在解析、锁文件、并发写入失败这些地方。
实际建表建议至少包含：id、post_id（关联文章）、author_name、author_email（可选）、content、created_at、status（0=待审核，1=已发布）。别省掉 status 字段——上线后你一定会遇到垃圾评论或误提交。
PHP 接收评论时必须做哪些校验？
只靠前端 required 或 JS 提示完全不可靠，攻击者直接 curl 就能绕过。服务端至少要检查三件事：
-
$_POST['content']长度是否在合理范围（比如 5–1000 字），太短可能是灌水，太长可能含恶意 payload -
filter_var($_POST['email'], FILTER_VALIDATE_EMAIL)验证邮箱格式（如果收集邮箱） - 用
htmlspecialchars($_POST['content'], ENT_QUOTES, 'UTF-8')转义内容再入库，防止 XSS；显示时也得用同样方式转义，不能只依赖入库前处理 - 加简单防刷：检查
$_SERVER['HTTP_REFERER']是否来自本站评论页，或验证 session 中是否存在 5 分钟内生成的comment_token
如何避免评论提交后页面刷新丢失内容？
用户填了 300 字结果点提交跳转 404，体验极差。核心思路是把提交逻辑从传统表单 POST 改成 AJAX：
立即学习“PHP免费学习笔记（深入）”；
- 前端用
fetch()或jQuery.ajax()发送POST /api/comment.php -
comment.php只负责接收、校验、入库、返回 JSON（如{ "success": true, "id": 123 }），不输出 HTML - 成功后清空表单 + 滚动到新评论位置；失败则在表单下方用
<div class="error"></div>显示$errors数组里的提示
注意：别为了“省事”在 AJAX 成功回调里用 location.reload()，这等于又回到刷新老路。
显示评论列表时怎么处理嵌套回复和性能？
一级评论直接 SELECT * FROM comments WHERE post_id = ? AND status = 1 ORDER BY created_at DESC LIMIT 20 即可。但真要做“回复某条评论”，不要当场查出所有子评论拼进 HTML——容易 N+1 查询。
更稳的做法：
- 在评论表加一个
parent_id字段（默认为 0），所有回复都指向被回复评论的id - 查列表时只取
parent_id = 0的主评论；点击“查看回复”再用 AJAX 加载SELECT * FROM comments WHERE parent_id = ? - 如果评论量超过 500 条，务必给
post_id和parent_id加索引，否则ORDER BY created_at会变慢
另外，别在循环里反复调用 date('Y-m-d', $row['created_at'])，提前用 FROM_UNIXTIME(created_at, '%Y-%m-%d') 在 SQL 里格式化好，减少 PHP 层计算。
