很多人说预约前端无非就是“看日历、点个时间、填表提交”。但企业版 appointment 的前端拆得很细：后台管理侧的 slot 建模、网站侧的可用时段交互、最终提交表单的记忆与校验，其实是三段不同状态机。
一、后台管理侧先把 slot 当成独立对象管理
appointment_calendar_model.js 会维护 data.slots、默认时长、slotId，并在 buildRawRecord() / processPartialSlotRecord() 中处理时长、全天事件和标题格式。说明在管理端，slot 不是简单拖一个 event，而是一个带格式化逻辑的前端对象。
appointment_calendar_controller.js 又通过 _getSlots() 把这些 slot 序列化给后端，用于创建或更新 custom appointment type。这让前端编辑和后端持久化形成了清晰边界。
二、网站选时段不是展示结果，而是不断重算
appointment_select_appointment_slot.js 里，时区、资源、staff、容量选择变化都会触发 onRefresh()；selectFirstAvailableMonth()、renderNoAvailabilityForMonth() 则负责在没有可约时段时主动切换展示语义。
这意味着用户看到的可约时段不是一开始就算好的静态列表，而是会随着：
- timezone 切换；
- 资源选择；
- 容量选择；
- staff 选择；
不断重算的交互结果。
三、容量反馈是即时的，而不是提交后报错
_updateResourceCapacityOptions() 会根据当前资源的最大容量重建 capacity 选项。这个细节很实用：系统不是让用户先选一个不可能的容量，等提交时再告诉你失败，而是在交互过程中就尽量把不可能选项删掉。
四、最终表单还要承担“少填一次”的记忆体验
appointment_form.js 在 start() 里会尝试从 localStorage 读取上次填写的 name/email/phone；onConfirmAppointment() 又会在校验通过后把核心字段写回 localStorage。再加上 guest 邮箱上限和非法邮箱校验，它实际解决的是：
- 老访客重复预约少填一次；
- guest 输入不要失控；
- 表单错误尽量前置到提交前。
五、新手误区
1. 以为预约时段就是后端吐一段 HTML
前端自己维护了一整套 slot 状态与刷新机制。
2. 以为时区只是显示格式问题
时区切换直接影响 slot 可用性与展示。
3. 以为 attendee form 只是普通网站表单
它还负责 guest 交互、缓存默认值和提交前约束。
六、实战注意事项
- 预约相关定制要分清管理端 slot 编辑和网站端 slot 选择，不要混改；
- 改资源容量逻辑时，务必同步测试 option 重建与最终提交；
- localStorage 记忆虽好用，但字段扩展时要注意兼容旧值；
- 没有时段的月份和首个可用月份跳转，是最容易漏测的边界。
结语
企业版预约前端真正做的，不是“让用户点一个时间”，而是把slot 管理、可用性重算、容量反馈和表单记忆串成一条顺滑的预约体验链。理解了这条链，你就不会再把它当成一个普通表单页。
DISCUSSION
评论区