Sublime Text 仅是文本编辑器，无法独立开发完整会议室预约与签到系统；它可编写前端页面、配置文件、轻量脚本及整理名单，但依赖外部服务实现后端、数据库、二维码跳转与状态闭环。
Sublime Text 本身不支持直接开发完整的会议室预约与签到系统——它只是个代码编辑器，没有后端、数据库或二维码生成功能。想用它“开发”，本质是拿它写前端页面、配置文件或脚本，再依赖外部服务或工具补全能力。
为什么不能只靠 Sublime Text 做完整系统
Sublime Text 是纯文本编辑器，不提供：HTTP 服务器、数据库连接、二维码生成函数、用户身份验证。你用它写一个 index.html 页面，保存后双击打开，浏览器里只能看到静态内容；没人能提交表单，座位数据不会存储，扫码也根本不会跳转到任何逻辑处理页。
常见误解是：把“在 Sublime 里写了 HTML+JS”等同于“做出了系统”。实际上，那只是界面雏形，离可用差至少三步：部署环境、接入后端、对接真实服务（如草料二维码 API 或云会助活码）。
Sublime 可以实际承担哪些角色
它适合做以下几类事情，前提是已有明确技术栈和分工：
- 编写前端页面：用
HTML+CSS+JavaScript搭建预约表单、座位图展示页、签到结果页 - 编辑配置文件：比如修改
config.json中的会议室列表、默认时段、二维码跳转链接 - 写轻量脚本：用 Python 插件（需装
SublimeREPL）快速测试qrcode库生成本地二维码图片（仅限开发调试，不能用于生产签到） - 整理和校验参会名单：用正则批量清洗
attendees.csv中的手机号格式、去重、补全空字段
二维码生成必须绕开 Sublime 直接调用外部服务
你在 Sublime 里写 import qrcode 并运行，只能生成一张本地 PNG 图片，无法实现“扫码→查座位→记录签到状态”这个闭环。真正可用的二维码必须指向一个可访问的 URL，而这个 URL 背后要有：
- 一个能接收 GET 请求的接口（如
/checkin?uid=123） - 一套绑定人员信息与座位号的映射逻辑（通常存在数据库或 JSON 文件中）
- 权限控制（防止别人伪造链接直接标记自己为已签到）
所以实践中更可行的路径是：用 Sublime 编辑好前端页面后，把页面部署到 Netlify 或 Vercel，再用草料二维码的「活码」功能，将二维码指向该页面，并开启「动态参数」传入 name 或 seat_id，由页面 JS 解析并渲染对应座位信息——整个过程里，Sublime 只管写页面，不碰服务逻辑。
座位管理别手动画 DOM，优先用现成结构化方案
有人习惯在 Sublime 里手动写几十个 来画座位图，这会导致后期维护极难：换布局就得改 HTML，加新区域就得重写 CSS Grid，移动端适配几乎归零。
更合理的方式是：
- 用 JSON 描述座位结构：
seats.json包含[{"id":"A1","row":"A","col":1,"type":"vip"},{"id":"B3","row":"B","col":3,"status":"booked"}] - 用 JavaScript 动态渲染（Sublime 只编辑这个 JSON 和 JS 逻辑）
- 座位状态变更走 API 更新，而不是靠人工改 HTML
这样一旦后续要接入企业微信审批流或钉钉日程同步，只需替换数据源，UI 层基本不动。
真正卡住进度的往往不是写代码，而是没想清楚：二维码扫完之后，那个“显示座位”的页面，它的数据从哪来、谁负责更新、怎么防刷。Sublime 再快，也填不上这个设计断层。
