结论先行
“客户在官网选时间、付钱、系统建个任务”听起来像一条线，其实源码里至少跨了四层：预约先落成 calendar.booking，支付模块围绕发票/交易做校验，付款成功后才生成 calendar.event，最后 website_appointment_sale_project 再把带预约上下文的销售行转成项目/现场服务任务。
第一层：入口或表面动作
appointment_account_payment 的核心判断是：预约不是付款成功后才创建，而是先创建 booking，再把 booking 挂到付款流程里。calendar_booking._make_invoice_from_booking 会先建 draft invoice；控制器 _redirect_to_payment 再把 appointment type、invoice、partner、amount、access token 全带进 /payment/pay。这样设计的好处是，网站层已经把时段、资源、客户信息冻结到 booking 上，支付只负责把这份候选预约变成已付款预约。
第二层：真正的业务护栏
付款落地后，payment.py 的 appointment_post_payment 不会直接相信浏览器传参，而是用 invoice_token 反查 account.move，再回到 calendar_booking_ids 找 booking。若 booking 已经有 calendar_event_id，就跳转到事件视图；否则仍停留在 booking summary。真正把预约变成日程的是 calendar_booking._make_event_from_paid_booking：它会先 _filter_unavailable_bookings()，把冲突时段挡掉，再调用 appointment type 的 _prepare_calendar_event_values() 建 event。也就是说，支付成功不是最终真相，可用性复核仍然发生在付款之后的落地阶段。
第三层：状态落点与边界
最后一棒在 website_appointment_sale_project。销售行 _action_confirm 会在订单确认或成功付款后，先对已有 calendar_event_id 做 action_unarchive()，再调用 calendar_booking_ids._make_event_from_paid_booking()；随后 _timesheet_create_task_prepare_values 把 calendar_event_id、所选 staff、资源标签、开始结束时间、allocated_hours注入 task 值，_timesheet_create_task` 还会把预约参与者订阅到任务消息流。于是一个网站预约并没有停在“付款完成”，而是继续穿过 sale/project，变成了一个带日程、参与者与工时上下文的执行对象。
为什么这套设计更稳
这条链最大的价值，是每个模块只接自己的责任。appointment 负责收集时段与容量，payment 负责交易可信度，calendar 负责最终资源占用，sale/project 负责交付对象生成。你如果试图在网站控制器里一步到位建 task，后面所有退款、支付失败、时段冲突、参与者同步问题都会一起反噬。
实战启示
因此调试这类问题时，不要只盯 task 有没有生成。先看 booking 是否建立、invoice 是否关联、payment return 是否反查到正确 invoice、_filter_unavailable_bookings 有没有把候选时段踢掉，最后才看销售行转任务时是否带到了 event/user/tag。跨模块链路一旦拆开，每一层的问题都能被单独证明。
DISCUSSION
评论区