我是杨家淋，一名后端开发者，日常用 Python 与 Django 搭建面向真实用户的 Web 系统。从需求拆解、数据建模到接口设计与上线运维，这条链路一走就是几年。这个站点存放工作中的判断和笔记，不追求信息量，只保留经得起重复验证的部分。
关于我
我目前在一家做行业软件的公司负责服务端开发，团队不大，从表结构到部署脚本常一个人盯到底。这种环境逼出一个习惯：先想清楚边界，再写代码。权限属于谁、状态怎么流转、失败之后如何回滚，在动手前回答清楚，后面能省下大量返工。
在做什么
近两年主要做一件事：把运行七年的单体系统拆开。订单、结算、权限三块业务彼此纠缠，直接重写风险太高，于是采用绞杀者模式，新功能落在独立模块，旧逻辑按调用频率排队迁移，每步保留双写与灰度开关，任何一次发布都能在十分钟内退回。
另一个方向是查询性能。Django 的 ORM 写着舒服，稍不注意就会在循环里触发成百上千次查询。我的排查流程是：先看慢日志，再定位重复查询，用 select_related 与 prefetch_related 收口，最后补上针对性索引，多数接口从数百毫秒降到几十毫秒。
技术栈与取舍
服务端以 Python 3.12 与 Django 5 为主，数据库用 PostgreSQL，缓存与队列交给 Redis，静态资源由 Nginx 承担，部署走容器加一条简单流水线。组合不新潮，但文档齐全、社区成熟。
取舍原则很朴素：能用成熟方案解决的不自己造轮子，必须自研的一定写清楚为什么。权限模型我没有引入通用框架，而是按业务梳理出资源、动作、范围三个维度，几十行代码实现，反而更容易维护。
一些具体的经验
迁移文件要小而可回滚，一次只改一件事；大表加字段先加可空列再回填，避免长时间锁表。时区统一存 UTC，展示层按用户所在时区转换，这个约定省掉很多跨日统计的争议。
写作与分享
我把踩过的坑写成短文，集中在 ORM 查询优化、迁移冲突处理、时区与序列化，标准只有一个：读者照着做能复现同样的结果。
如果你也长期维护一套 Django 项目，希望这里的记录能替你省下几个深夜。
联系方式
这个页面由我本人维护，可通过页面底部的备案号核验主体归属。技术交流欢迎围绕具体问题展开，附上复现步骤、版本号与报错信息即可。