企业官网建设流程全解析

2. 初版用的是单表存经纬度，然后按距离排序筛选。数据量小的时候没问题，但车位一旦过千，这个计算量就很尴尬。后来改成了方框粗略筛选加距离精排的两段式方案。先根据当前坐标和搜索半径算出经纬度上下限，用ORM的filter把范围缩到几百条内，再对这批数据精确算距离排序。这个方案在日常场景下足够用，而且实现简单。

3.2 预订时段冲突检测与锁定

只要车位的资源匹配逻辑靠谱，并发冲突就少。这里我设计了不能重叠和可以重叠两类场景。出租车位是按时间段租给一个人的，两个订单的时段不能重叠；临时租用则以小时为单位，同一时段同样不能重复预订。

检测冲突的SQL其实很简单，在过滤条件里同时判断时间交叉的四种情况即可。真实场景里，更重要的是把冲突检测做成原子操作。我用了一个比较朴素的方案：在创建订单时，先对车位记录执行select_for_update，锁定车位行，再查询该车位上的有效订单有没有时间段重叠，没有才写入订单。

注意：select_for_update必须在事务内使用。这一行锁的作用就是串行化同一车位的预订请求，避免两个人同时看到有空位、同时下单的竞态问题。上线初期这个方案一直很稳，订单量大了之后再用Redis分布式锁也别怕，逻辑本质是一样的。

订单状态流转方面，我按照“待支付 -> 已支付 -> 使用中 -> 已完成 -> 已取消”这条链路设计了状态机，并且用一张状态日志表记录每次变更。做状态机的最大好处是避免乱跳，比如一个已完成的订单不能直接取消。这个业务的订单状态比较常规，不搞重型工作流，一个状态字段加几个条件判断就够了。

3.3 支付对接与回调处理

支付我接的是线上支付平台的模拟接口。真实对接时，支付回调的验签和幂等处理是必须注意的。回调通知到达后，第一件事是验签，第二件事是根据订单号和交易号查库，确认这笔订单确实存在且状态是待支付。如果订单已经完成，说明回调重复了，直接忽略返回成功。这步幂等要是没做好，很容易出现支付成功但订单状态被打回待支付的诡异Bug。

支付成功后的业务动作不止是改订单状态，还要做两件事：一是给车位租用方发消息通知，二是往车主的账户里记账。为了不因为某个环节报错导致主流程失败，我把这些后续动作放到了事务提交后的信号里去执行。Django的transaction.on_commit在这里很好用，提交成功后才触发短信和记账任务，哪怕这两步失败了，也不会影响支付结果本身。

4. 前端交互与后台管理落地

4.1 用户端页面与API交互要点

页面层面分了两种入口：访客浏览和登录操作。首页可以直接搜索周边车位，但预约和下单必须登录后操作。这个规则在视图层和模板里都做了校验，避免有人绕过前端直接构造请求下单。

前端技术栈用的还是Django模板加少量JavaScript。搜索页用一个区域块展示车位卡片，每张卡片显示车位名称、地址、距离、价格和可预约时段。这里的距离是后端计算好的，传到模板直接展示。用模板引擎渲染的好处是服务端渲染，首屏体验不错，也不用额外维护前端路由。

预订流程分三步：选择车位进入详情页 -> 选择时段确认金额 -> 提交订单去支付。每一步都有对应的URL和视图函数。最开始是三步合一、一次性提交，但用户体验不够好，无法确认车位详情。拆开后其实逻辑更清晰，每步视图的代码量也少，坏账率显著下降。

前端这里有个容易被忽略的坑：列表页和详情页显示的价格必须由后端从车位关联的价格表读取，不能由前端传值。提交订单的时候，金额要以服务端重新计算的为准，前端传过来的金额仅仅是展示参考。否则改一下请求参数，就能用1块钱订一天的车位。

4.2 管理后台定制：发布审核与数据统计

Django自带的admin后台在这个项目的价值非常高，甚至可以说是整个项目能快速交付的关键。我把车位管理、订单管理、用户管理直接接入admin，然后针对运营场景做了一些定制。

车位发布后需要管理员审核，我在车位模型上加了audit_status字段，默认待审核。admin后台的列表页增加了审核状态筛选框和管理员操作按钮。操作按钮通过自定义Admin Action实现，选中多个车位可以一键批量审核通过，运营同学直呼这功能实在。

数据统计这块，我没有额外引入图表库，直接在admin后台加了几个只读的统计页面，展示每日订单量、成交金额、车位新增数。用Django的extra_tags和自定义视图就能解决，数据来源于订单表的create_time做TruncDate分组统计。报表虽然朴素，但胜在可靠，运营看数据完全够用。

提醒一下，admin后台虽然开发效率高，但暴露在公网上之前一定要做访问限制。我用了两层防护：第一层是路由上不把admin放在默认的/admin/路径，改成一个不易猜测的路径；第二层是对admin的视图做IP白名单和登录权限校验。不要小看这个默认路径，网上扫描器遍地都是。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

开发过程中有几个问题反复被踩，我整理成了速查表，供后来者直接对照。

5.2 性能优化与开发效率心得

说到性能，这个系统的瓶颈不在数据库查询，而在图片上传和列表页渲染。车位照片是用户上传的，最初直接把原图存下来，列表页一次加载几十张几兆大小的图片，页面耗时直接拉满。后来我做了图片压缩，上传时用Pillow把长边缩到800像素并转成JPEG格式，性能提升了不止一个量级。

列表页渲染方面，除了select_related预取关联表之外，还有一个技巧：把车位描述这类大文本字段在列表查询时排除掉，用ORM的only方法指定需要的字段，减少数据传输量。别小看这个操作，车位数上来以后，列表接口的响应时间能降一半。

开发效率方面，我想说一件事：先用admin把后台跑通，再补前台。这个顺序能少走很多弯路。admin后台天然帮你把增删改查、权限、分页都做了，业务逻辑在里面校验通过后，前台页面只是换一层皮。如果一开始就埋头写前台视图和表单，整个项目节奏会慢很多，还容易遗漏数据维护入口。

6. 几点真心话

这套车位共享系统，我从数据模型设计到上线部署，前后用了不到两周的时间。Django的确是很适合这类项目的框架，它的ORM、Admin和信号机制让业务开发从繁琐的重复劳动里解放了不少。我在实际开发中最大的体会是：先把数据模型和状态流转理清楚，再去写页面，基本上不会有大返工。数据结构稳了，业务逻辑就稳了，页面只是数据的呈现方式。

另外，想给正在做类似系统或者准备仿照这个项目练手的朋友一个建议：别一开始就想着把所有功能都堆上去。车位共享的核心就是发车位、搜车位、下订单、做支付、管状态。把这几条链路打磨顺了，比增加评论点赞分享这些辅助功能有价值得多。代码写到最后，真正决定工程质量的是那些看不见的地方——权限控制、异常处理、日志记录、并发锁，这些才是系统能长期稳定运行的关键。

最后再分享一个小技巧：开发时一定要早早在关键业务操作里埋上日志。比如订单状态变更、支付回调、用户注册，这些地方打点，线上出问题时你能省下大半排查时间。我就是被线上问题查了两天之后，才把所有关键流程的日志老老实实补齐的。日志是你和线上系统的对话窗口，别省这几行代码。