纯HTML不能做真正可交互的论坛，仅能实现静态展示；用户发帖需手动提交JSON文件至GitHub仓库，通过JavaScript读取渲染，依赖人工协作与CI校验保证格式统一。
用纯 HTML 能不能做论坛交流区
不能做成真正可交互的论坛——HTML 本身不处理用户输入、不保存数据、不校验登录，它只是页面“骨架”。所谓“简版”，实际是静态展示区：别人发的帖子你能看，但你点“发帖”按钮后，内容不会存到服务器，也不会显示在页面上。这点必须先认清楚，否则后面所有尝试都会卡在“为什么我填了表单没反应”上。
form 标签加 action="mailto:" 算不算提交
算，但仅限本地邮件客户端触发，且无法回传或存档。用户点击提交后，会打开系统默认邮件软件（如 Outlook 或 Mail），预填收件人和内容，但发不发、发没发成功、谁发的——网页完全不知道。
-
action="mailto:admin@site.com?subject=新帖子"可带主题和简单正文（用&body=xxx编码拼接） - 所有字段必须用
name属性，否则mailto不识别；中文要encodeURIComponent处理，否则乱码 - 没有服务端，就不存在“帖子列表自动刷新”，你得手动把收到的邮件复制粘贴成 HTML 片段再上传更新页面
想让别人看到“已发内容”，最轻量的替代方案是什么
放弃“实时”和“多人并发”，改用 GitHub Pages + 静态 JSON + 小型脚本控制显示。核心思路：把每条帖子存成独立 .json 文件（如 post-001.json），用 JavaScript 读取并渲染；新增帖子靠手动提交 PR 或直接 push 到仓库——本质是“协作编辑一个公开的 JSON 目录”。
- 每个
post-xxx.json至少含：title、author、content、date字段 - 前端用
fetch()加载/posts/目录下所有 JSON，按date倒序排列渲染 - 别用
XMLHttpRequest，GitHub Pages 默认禁用跨域，fetch更稳妥；注意浏览器缓存，开发时加时间戳参数绕过 - 用户“发帖”实际是：下载模板 JSON → 填内容 → 提交到仓库
/posts/目录 → 等 GitHub Pages 自动构建生效（通常 1–2 分钟）
为什么不用现成的静态评论系统（如 Utterances、Giscus）
它们能用，但依赖 GitHub Issue，不是“论坛”而是“页面级评论”。每篇文章对应一个 Issue，所有回复挤在一条线程里，不支持分类、不支持搜索、不支持置顶、不支持用户主页——连基本的“发帖→列表→点开看详情”三层结构都缺。
立即学习“前端免费学习笔记（深入）”；
- Utterances 把评论存在 repo 的 Issues 里，但
/posts/下每个 JSON 是独立资源，结构自由，可加标签、状态、阅读数字段 - Giscus 同样绑定 Issue，且要求用户登录 GitHub 才能评论，对普通访客门槛高
- 如果真要“交流区”，哪怕极简，也得有明确的帖子 ID、独立 URL（如
/p/001.html）、可分享链接——这些静态评论系统都不提供
真正卡住的点从来不是写几行 html，而是数据从哪来、谁负责维护、别人怎么参与。静态方案里，“谁提交 JSON”就是管理员，“怎么保证格式统一”靠 README 里的模板和 CI 检查。别指望一键部署，先接受它是个需要人工介入的协作流程。
