sublime text 仅是代码编辑器，无法运行医院预约挂号系统后端；号源管理需数据库事务、并发控制和http服务，必须部署到真实服务器环境，sublime只负责编写django/flask等框架代码。
Sublime Text 本身不支持直接开发后台模块，它只是代码编辑器，不能运行或部署医院预约挂号系统——所有后端逻辑（号源管理、科室分类配置）必须由真实服务器环境承载，Sublime 只负责写代码。
为什么不能在 Sublime 里“集成号源管理”
号源管理涉及数据库读写（如每日可约号数、医生排班、余号实时扣减）、并发控制（多人抢号）、事务一致性（挂号+扣号+生成订单需原子执行）。Sublime 没有 HTTP 服务、没有数据库驱动、没有进程调度能力。你看到的任何“Sublime 后台开发”描述，实际是用 Sublime 编辑 Python（Django/Flask）、Java（Spring Boot）、Node.js（Express）等服务端代码，再部署到 nginx+gunicorn 或 Tomcat 等容器中运行。
- 常见错误现象：
ImportError: No module named flask或Connection refused—— 误以为保存.py文件就能访问/api/available-sources - 正确做法：用 Sublime 写好
views.py中的get_available_sources()函数，然后在终端执行python manage.py runserver - 科室分类配置若存于 JSON 文件（如
departments.json），Sublime 可高效编辑，但加载逻辑（json.load(open('departments.json'))）必须由后端框架执行
Sublime 实际能帮上忙的关键点
它在开发效率上的优势集中在静态结构和快速调试支持，而非运行时能力：
- 安装
SublimeLinter+flake8插件，实时标出def update_source_count():中缺少return的逻辑漏洞 - 用
Ctrl+Shift+P调出命令面板，输入Sync Settings备份你配置的hospital-api.sublime-settings（含 API 域名、测试 token） - 对科室树形数据（如
{"id": "derm", "name": "皮肤科", "children": [...]}），用Ctrl+Shift+P→JSON Reindent快速格式化，避免因缩进错乱导致json.decoder.JSONDecodeError - 设置项目专属构建系统（
Tools → Build System → New Build System），内容为：{ "cmd": ["python", "-m", "http.server", "8000"], "working_dir": "$project_path/backend" }——这样按Ctrl+B就能本地起一个静态文件服务，用于预览科室配置页（但注意：这仍不是真正的挂号后台）
号源管理代码容易踩的坑（Sublime 编辑时需盯紧）
即使逻辑写对，细节疏忽会导致超约、号源不释放、科室映射错乱：
-
source_count字段必须设为数据库INT UNSIGNED类型，否则扣减时出现负数（如 MySQL 中UPDATE sources SET count = count - 1 WHERE id = 123在 count=0 时变成 -1） - 科室分类若用缓存（如 Redis），Sublime 编辑
cache_key = f"dept_tree_{hospital_id}"时，要确认hospital_id来源是否可信（不能直接从 URL query 参数取，需经 session 验证） - 号源释放逻辑（如用户取消挂号）必须检查状态：只有
status == 'confirmed'才允许回填，否则status == 'paid'的号被释放会导致财务对账失败 - 前端传来的科室 ID（如
dept_id: "cardio"）和服务端数据库字段department_code必须严格一致——Sublime 的Find All（Alt+F3）可批量核对拼写
真正决定号源是否可靠、科室配置能否生效的，从来不是编辑器有多快，而是数据库事务隔离级别是否设为 REPEATABLE READ、Redis 锁的 key 是否包含医生 ID 和日期维度、科室树形结构的递归查询有没有加 WITH RECURSIVE 防止无限循环。Sublime 只是你看清这些逻辑的第一双眼睛，别让它替你承担本该由服务器扛的责任。
