当前位置：首页 > news >正文

Django救场实战：18天交付企业级库存系统

news 2026/7/6 11:04:08

1. 项目概述：一个被低估的Web开发救场时刻

“Django Saves the Day”——这名字听起来像某部美剧的片名，但在我过去十年带团队做企业级系统交付的过程中，它早已成了我们内部一句带着喘息感的口头禅。不是夸张，是真的“救命”。去年底给一家区域性连锁药店做库存预警+处方流转系统时，客户原定的供应商在UAT前两周突然撤场，留下一个用Express.js搭的半成品：前端能点，后端API返回404，数据库字段命名混着英文和拼音，连基础的药品批次效期校验逻辑都写在Vue组件里。留给我们的窗口期只有18天。我们没开评审会，没写PPT，三个人围在白板前画了47分钟流程图，当晚就敲下第一行django-admin startproject pharmacy_core。不是因为Django多酷炫，而是它把“能跑通、能上线、能改、能扛住压力”这四件事，打包成了一套可预测、可复用、可交接的工程范式。它不解决所有问题，但它把90%的重复性基建问题提前封进了框架契约里：URL怎么映射、表单怎么验证、权限怎么分层、日志怎么落盘、静态文件怎么托管……这些事你不用从零造轮子，更不用在凌晨三点对着Node.js的异步回调栈发呆。它适合谁？适合那些真正要交付业务价值、而不是秀技术参数的团队；适合被KPI压着、需要在“功能完整”和“上线时间”之间找平衡点的产品经理；也适合刚转行的开发者——你不需要先背完HTTP状态码全表，就能让一个带登录、增删改查、数据导出的管理后台跑起来。它解决的从来不是“能不能做”，而是“能不能稳、能不能快、能不能少踩坑”。

2. 核心设计思路拆解：为什么是Django，而不是别的？

2.1 “救场”背后的三层确定性逻辑

很多人觉得选Django是“保守”或“过时”，但真正的救场能力，恰恰来自它对确定性的极致追求。这种确定性不是靠文档厚度堆出来的，而是由三个相互咬合的层次构成的。

第一层是约定优于配置（Convention over Configuration）的工程契约。比如，当你执行python manage.py startapp inventory，Django自动创建models.py、views.py、admin.py、apps.py四个文件，并默认将inventory注册进INSTALLED_APPS。这不是偷懒，而是强制你在项目初期就面对一个关键问题：这个模块的职责边界在哪里？模型定义放models.py，业务逻辑放views.py，管理后台配置放admin.py——这种物理隔离，直接规避了后期代码散落在20个文件里、新人根本找不到入口的灾难。我见过太多用Flask的项目，三个月后app.py膨胀到3000行，路由、数据库连接、中间件、错误处理全挤在一起，改一个登录逻辑得同时盯五六个函数。而Django的目录结构，本质上是一份用文件系统写成的架构说明书。

第二层是开箱即用的生产就绪组件（Batteries Included）。这里的关键不是“功能多”，而是“功能组合的合理性”。拿用户认证系统来说，Django内置的auth模块包含：密码哈希（PBKDF2 + SHA256，默认迭代150000次）、会话管理（支持数据库/缓存/文件多种后端）、权限系统（基于组和权限码的RBAC）、密码重置（带时效Token和邮箱验证）。你不需要去GitHub搜十几个第三方包，再花三天调试它们之间的兼容性。去年帮一家教育机构做家长端报名系统，他们要求“手机号一键登录+微信授权+老账号密码迁移”，我们只用了Django的auth基础框架，外加两个自定义的Backend类（一个处理短信验证码校验，一个处理微信OpenID绑定），核心逻辑不到200行。对比隔壁用Spring Boot的团队，光是整合Shiro和Redis Session就卡了五天。

第三层是可预测的性能与扩展路径。Django不是为百万QPS设计的，但它的瓶颈非常清晰：90%的慢请求来自N+1查询、模板渲染阻塞、同步IO等待。而它的调试工具链（django-debug-toolbar、django-silk）能精准定位到哪一行QuerySet触发了额外的数据库访问。我们有个电商后台，高峰期订单列表页加载要8秒，装上debug-toolbar后发现是OrderItem模型的product.name字段触发了127次单独查询。改成select_related('product')，响应时间降到600毫秒。这种“问题-工具-解法”的闭环，让救场时的优化有迹可循，而不是靠玄学重启服务。

提示：Django的“确定性”是双刃剑。它不适合需要极致定制化路由规则（如动态正则匹配上百种URL模式）或必须用协程处理百万长连接的场景。救场的前提，是你面对的是典型的CRUD+业务逻辑+有限并发的中后台系统。

2.2 为什么不是FastAPI或Tornado？

常有人问：“现在都2024年了，为什么不用FastAPI？它自带OpenAPI文档、异步支持、类型提示，看起来更现代。” 这是个好问题，答案藏在“救场”的本质里——时间成本不是写代码的时间，而是决策、试错、联调、回滚的总时间。

FastAPI的异步能力，在绝大多数中后台场景中是闲置资源。我们做过压测：一个带数据库查询的Django视图（使用psycopg2同步驱动）和一个等效的FastAPI视图（使用asyncpg），在100并发下，平均响应时间差异不到15ms。但代价是什么？你需要理解async/await在Web框架中的生命周期（比如request.state在中间件中的传递限制）、处理同步库（如Pandas数据处理）的线程池封装、调试异步上下文丢失的诡异bug。去年有个物流轨迹查询接口，FastAPI版本在高并发下偶发返回空数据，排查三天才发现是某个第三方SDK的全局变量在异步任务间被污染了。

而Django的同步模型，反而成了稳定器。它的请求-响应周期是线性的：接收请求→执行视图函数→渲染模板→返回响应。每一步的输入输出、副作用、错误边界都清晰可见。当客户凌晨两点打电话说“报表导出失败”，你SSH进服务器，tail -f /var/log/django/app.log，错误堆栈直接指向export_views.py第87行——是Excel写入时内存溢出。换作一个复杂的异步链路，你可能得先理清asyncio.run()的事件循环嵌套关系，再确认aiofiles的缓冲区配置是否合理。

Tornado的问题则更底层：它没有内置的ORM、没有成熟的Admin后台、没有统一的表单验证体系。你要自己拼凑一套“能用”的系统，光是实现一个带搜索、分页、导出的药品管理列表页，就得手写SQL查询、手动处理GET参数分页、自己写CSV生成逻辑。而Django的ListView配合django-tables2，加上django-import-export，15分钟就能跑起来一个功能完整的页面。救场不是比谁代码更炫，而是比谁能让业务在最短时间内重新流动起来。

2.3 Django的“隐形护城河”：生态与人才密度

技术选型不能脱离人。Django的护城河，一半在代码，一半在社区。国内一线城市的Python岗位中，要求“熟悉Django”和“熟悉Flask”的比例常年维持在3:1以上。这意味着什么？当你在救场时缺人，招一个有Django经验的中级工程师，他第一天就能看懂settings.py的数据库配置、urls.py的路由分发逻辑、admin.py的字段显示规则。而如果用小众框架，你得先花两天给他讲清楚整个项目的约定。

更重要的是生态的成熟度。比如Excel导入导出，django-import-export这个包已经维护了12年，支持Django 4.2，文档里连“如何跳过空行”、“如何处理日期格式异常”都有详细示例。而如果你用FastAPI，得自己组合pandas、openpyxl、starlette的文件上传中间件，再处理各种Excel版本兼容性问题。我们曾为一个政府项目做数据上报系统，客户要求支持.xls、.xlsx、.csv三种格式，且字段顺序不固定。用django-import-export，我们只重写了import_data()方法里的字段映射逻辑，3小时搞定。换成从零写，保守估计要2天。

这种生态红利，是救场时最珍贵的“时间缓冲垫”。它让你能把有限的精力，聚焦在真正的业务差异点上——比如药店系统的效期预警算法、教育平台的课程推荐策略——而不是反复造轮子。

3. 核心细节解析与实操要点：从零到上线的关键切口

3.1 救场第一步：砍掉80%的“完美主义”需求

救场最大的陷阱，不是技术难度，而是试图一次性解决所有问题。Django再强大，也不能帮你把客户三年内想到的所有功能都塞进18天。我们必须建立一条“最小可行救场线”（MVRS, Minimum Viable Rescue Scope）。

以药店库存系统为例，客户原始需求清单有43项。我们用Django的特性做了三次筛选：

第一次，按Django内置能力过滤：去掉所有需要“实时消息推送”（WebSocket）、“复杂图形报表”（ECharts深度集成）、“多语言动态切换”（i18n需额外配置）的需求。这些不是不能做，而是它们需要额外的框架层（如Channels）、前端工作量、测试周期，不在MVRS内。
第二次，按业务连续性排序：保留“药品入库登记”、“销售出库扣减”、“库存不足预警邮件”、“管理员后台登录”这四项。理由很朴素：只要这四件事能跑通，药店明天就能正常进货、卖货、知道哪些药快没了、老板能查数据。其他如“供应商管理”、“员工排班”、“会员积分”，全部延后。
第三次，按Django Admin的适配度压缩：Django Admin天生适合管理型CRUD。我们把“药品入库登记”拆成两个动作：1）管理员在Admin里录入新药品信息（名称、规格、单位、批号、效期）；2）收银员用一个极简的FormView提交销售单（只需选择药品、输入数量）。前者完全用Admin实现，后者我们只写了12行视图逻辑+一个HTML表单。这样，80%的数据管理界面，我们没写一行前端代码。

注意：砍需求不是妥协，而是用Django的杠杆效应放大单位时间产出。Admin不是“简陋”，而是把“列表展示、搜索、分页、编辑、删除”这些通用能力，压缩成一个ModelAdmin类的几行配置。你省下的时间，可以用来打磨“效期预警算法”的准确性——这才是真正的业务价值。

3.2 模型设计：用Django ORM规避90%的数据一致性风险

救场时最怕什么？不是功能没做完，而是做完了，数据乱了。比如销售出库时，库存数量没扣减，或者扣减了但没记录流水。Django ORM的事务管理和信号机制，是防止这类事故的保险丝。

我们设计了三个核心模型：

# models.py from django.db import models from django.contrib.auth.models import User class Medicine(models.Model): name = models.CharField(max_length=100) spec = models.CharField("规格", max_length=50) # 支持中文字段名 unit = models.CharField("单位", max_length=10) # ... 其他字段 class InventoryLog(models.Model): """库存流水日志，所有库存变动必须经过此模型""" IN = 'IN' OUT = 'OUT' TYPE_CHOICES = [(IN, '入库'), (OUT, '出库')] medicine = models.ForeignKey(Medicine, on_delete=models.CASCADE) quantity = models.DecimalField(max_digits=10, decimal_places=2) log_type = models.CharField(max_length=3, choices=TYPE_CHOICES) operator = models.ForeignKey(User, on_delete=models.SET_NULL, null=True) created_at = models.DateTimeField(auto_now_add=True) class Inventory(models.Model): """当前库存快照，由InventoryLog触发更新""" medicine = models.OneToOneField(Medicine, on_delete=models.CASCADE) current_quantity = models.DecimalField(max_digits=10, decimal_places=2, default=0) def save(self, *args, **kwargs): # 强制通过log更新，禁止直接修改current_quantity raise RuntimeError("库存快照请通过InventoryLog更新")

关键设计点：

InventoryLog作为唯一数据源：所有库存变动（入库、出库）都必须创建InventoryLog实例。我们在视图层用transaction.atomic()包裹整个操作，确保“创建log”和“更新快照”要么全成功，要么全回滚。
Inventory模型的防御性编程：重写save()方法抛出异常，彻底杜绝任何绕过log直接修改快照的可能。这比写文档警告“不要直接改”有效一万倍。

利用Django信号自动更新快照：

# signals.py from django.db.models.signals import post_save from django.dispatch import receiver @receiver(post_save, sender=InventoryLog) def update_inventory_snapshot(sender, instance, created, **kwargs): if not created: return # 获取或创建库存快照 inventory, _ = Inventory.objects.get_or_create( medicine=instance.medicine, defaults={'current_quantity': 0} ) # 根据日志类型更新数量 if instance.log_type == InventoryLog.IN: inventory.current_quantity += instance.quantity else: inventory.current_quantity -= instance.quantity # 防止负库存 inventory.current_quantity = max(0, inventory.current_quantity) inventory.save()

这套设计，让我们在上线后三个月内，0起库存数量与实际不符的客诉。因为每一笔变动都有迹可循，且数据库层面无法绕过约束。

3.3 Admin后台：不是“凑合用”，而是“生产力核弹”

很多人把Django Admin当成临时方案，这是巨大误解。它其实是Django最被低估的生产力引擎。救场时，我们把它当作“业务方自助服务平台”来用。

核心配置技巧：

list_display的魔法：不只是显示字段，还能嵌入计算逻辑和链接。

# admin.py class MedicineAdmin(admin.ModelAdmin): list_display = ['name', 'spec', 'unit', 'low_stock_alert', 'view_logs'] list_filter = ['created_at'] # 自动添加右侧筛选栏 search_fields = ['name', 'spec'] # 自动生成搜索框 def low_stock_alert(self, obj): # 动态计算并显示预警状态 try: inv = obj.inventory return "⚠️ 库存不足" if inv.current_quantity < 10 else "✅ 正常" except Inventory.DoesNotExist: return "❓ 无库存记录" low_stock_alert.short_description = "库存状态" # 列标题 def view_logs(self, obj): # 生成链接，跳转到该药品的日志列表页 from django.urls import reverse url = reverse('admin:pharmacy_core_inventorylog_changelist') + f'?medicine__id__exact={obj.id}' return f'<a href="{url}">查看流水</a>' view_logs.allow_tags = True # Django < 4.0 需要，新版用format_html view_logs.short_description = "操作"

inlines构建关联数据一站式管理：药品入库时，往往要同时录入多个批次。我们用InlineModelAdmin把InventoryLog嵌入Medicine的编辑页，管理员在一个页面里就能完成“新增药品+录入首批次”，无需跳转。
actions批量处理：针对“批量设置效期”、“一键导出所有库存”这类高频操作，自定义Admin Action，几行代码就能生成顶部操作按钮。

实测效果：药店管理员培训半小时，就能独立完成日常药品录入、库存查询、流水追溯。他们不再需要每次找IT人员“帮我查一下XX药还有多少”，而是自己点几下鼠标。这才是真正的“救场”——把技术团队从重复劳动中解放出来，去解决更复杂的业务问题。

3.4 安全加固：救场不等于裸奔

救场容易让人忽略安全，但生产环境没有“暂时不安全”这回事。Django内置的安全防护，必须在第一天就启用。

CSRF保护：Django默认开启，但要注意模板中所有POST表单必须包含{% csrf_token %}。我们曾因一个手写的AJAX POST忘记加X-CSRFToken头，导致所有表单提交失败，排查了两小时才想起。
XSS防护：Django模板默认转义所有变量。但如果你用|safe过滤器或mark_safe()，必须确保内容绝对可信。我们有个需求是显示药品说明书（HTML格式），解决方案是：1）存储时用bleach.clean()清洗；2）模板中用|safe渲染。绝不允许前端直接传HTML字符串入库。
SQL注入免疫：Django ORM的查询方法（filter(),get()）天然防注入。但要警惕extra()和raw()方法——它们是后门。救场时，我们禁用所有raw()调用，所有复杂查询用Q对象和annotate()重构。
敏感信息隔离：.env文件管理SECRET_KEY、数据库密码。我们用django-environ包，settings.py中：
```
import environ env = environ.Env() environ.Env.read_env() # 读取.env SECRET_KEY = env('SECRET_KEY') DATABASES = { 'default': env.db(), }
```
然后在服务器上部署时，只部署.env，不进Git。SECRET_KEY生成命令：python -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"。

这些不是“锦上添花”，而是上线前的必检清单。漏掉一项，可能就是一次线上事故。

4. 实操过程与核心环节实现：18天倒计时全记录

4.1 Day 1-2：骨架搭建与环境标准化

目标：让manage.py runserver在本地和测试服务器上都能跑起来，且配置一致。

本地开发环境：我们放弃Virtualenv，直接用pipenv。Pipfile锁定Django 4.2.7（LTS版本）、psycopg2-binary、django-environ。执行pipenv install，10分钟搞定依赖。

Docker化部署：救场项目必须容器化，避免“在我机器上能跑”的扯皮。Dockerfile极简：

FROM python:3.11-slim WORKDIR /app COPY Pipfile* ./ RUN pip install pipenv && pipenv install --system --deploy COPY . . CMD ["gunicorn", "pharmacy_core.wsgi:application", "--bind", "0.0.0.0:8000", "--workers", "4"]

Nginx反向代理配置：nginx.conf中，静态文件（CSS/JS）直接由Nginx服务，动态请求转发给Gunicorn：

location /static/ { alias /app/staticfiles/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

数据库初始化脚本：init_db.sh自动创建数据库、用户、赋权，并运行migrate：

#!/bin/bash psql -U postgres -c "CREATE DATABASE pharmacy;" psql -U postgres -c "CREATE USER pharmacy_user WITH PASSWORD 'strongpass';" psql -U postgres -c "GRANT ALL PRIVILEGES ON DATABASE pharmacy TO pharmacy_user;" python manage.py migrate python manage.py createsuperuser --noinput --username admin --email admin@example.com

Day 2晚上，测试服务器上curl http://test-server-ip返回Django欢迎页。骨架完成。

4.2 Day 3-5：核心模型与Admin落地

目标：药品、库存、流水三个模型在Admin中可用，支持增删改查。

Day 3上午：定义Medicine模型，重点是字段语义化。spec字段加verbose_name="规格"，方便Admin自动显示中文标签。unit用CharField而非ChoiceField，因为药店单位太杂（盒、瓶、支、袋、克、毫升…），硬编码选项反而麻烦。
Day 3下午：InventoryLog模型，关键在log_type的choices。我们没用'IN'/'OUT'，而是用'in'/'out'（小写），因为Django Admin的URL参数（如?log_type=in）对大小写敏感，小写更稳妥。
Day 4：Inventory模型及信号。测试时发现一个坑：post_save信号在migrate创建初始数据时也会触发，导致Inventory表里出现脏数据。解决方案：在信号处理器开头加判断：
```
if kwargs.get('raw', False): return # 跳过dumpdata/loaddata触发的信号
```
Day 5：Admin配置。list_display加入low_stock_alert，用@admin.display装饰器替代旧版allow_tags（Django 4.0+）。search_fields加入'name__icontains'，支持模糊搜索。部署到测试服，让客户方管理员试用，收集反馈。

4.3 Day 6-10：业务逻辑攻坚与API暴露

目标：实现“销售出库”核心流程，并提供简单API供收银系统调用。

销售视图：我们没用Django REST Framework（DRF），因为DRF的学习曲线会吃掉两天。直接用JsonResponse写一个轻量API：

# views.py from django.http import JsonResponse from django.views.decorators.csrf import csrf_exempt from django.db import transaction import json @csrf_exempt def sale_api(request): if request.method != 'POST': return JsonResponse({'error': 'Method not allowed'}, status=405) try: data = json.loads(request.body) medicine_id = data['medicine_id'] quantity = data['quantity'] with transaction.atomic(): # 1. 创建出库日志 log = InventoryLog.objects.create( medicine_id=medicine_id, quantity=quantity, log_type=InventoryLog.OUT, operator=request.user # 此处需JWT鉴权，简化版先用session ) # 2. 信号自动更新快照 return JsonResponse({'success': True, 'log_id': log.id}) except Exception as e: return JsonResponse({'error': str(e)}, status=400)

URL路由：urls.py中：

from django.urls import path from . import views urlpatterns = [ path('api/sale/', views.sale_api, name='sale_api'), # ... 其他路由 ]

前端对接：收银系统用fetch调用，关键点：1）Content-Type: application/json；2）携带X-CSRFToken（从/api/csrf-token/接口获取）；3）错误处理捕获400状态码并提示“库存不足”。

Day 10下午，收银机成功打出第一张销售小票，库存数字实时减少。客户CEO当场拍板：“就用这个版本上线。”

4.4 Day 11-15：预警系统与自动化运维

目标：实现效期预警，并接入企业微信通知。

预警任务：用Django Q（异步任务队列）替代Celery（学习成本高）。settings.py中：

Q_CLUSTER = { 'name': 'DjangORM', 'workers': 4, 'recycle': 500, 'timeout': 60, 'compress': True, 'save_limit': 200, 'queue_limit': 500, 'cpu_affinity': 1, 'label': 'Django Q', 'redis': { 'host': '127.0.0.1', 'port': 6379, 'db': 0, } }

预警逻辑：每天凌晨2点扫描Medicine，找出效期在30天内的药品：

# tasks.py from django_q.tasks import async_task, schedule from django_q.models import Schedule from datetime import timedelta from django.utils import timezone def send_expiry_alert(): today = timezone.now().date() alert_date = today + timedelta(days=30) expiring_meds = Medicine.objects.filter(expiry_date__lte=alert_date) # 发送企业微信消息... for med in expiring_meds: send_wecom_message(f"⚠️ 药品 {med.name} 将于{med.expiry_date}过期，请及时处理！") # 启动定时任务 schedule('pharmacy_core.tasks.send_expiry_alert', schedule_type=Schedule.DAILY, next_run=timezone.now().replace(hour=2, minute=0))

日志监控：LOGGING配置中，将django.db.backends的日志级别设为DEBUG，输出到/var/log/django/db.log。配合logrotate每日切割，避免日志撑爆磁盘。

4.5 Day 16-18：上线准备与知识转移

目标：平稳上线，确保客户方能自主运维。

性能压测：用locust模拟100并发用户访问库存列表页。发现瓶颈在Medicine模型的__str__方法（它拼接了太多字段）。优化：重写__str__，只返回self.name。

备份脚本：backup_db.sh每天凌晨1点自动备份：

#!/bin/bash DATE=$(date +%Y%m%d) pg_dump -U pharmacy_user pharmacy > /backups/pharmacy_$DATE.sql find /backups -name "pharmacy_*.sql" -mtime +7 -delete

知识转移文档：不是写技术手册，而是写《药店管理员自助指南》：
- 如何在Admin里查找某药品的全部流水？
- 如何导出本月销售报表？（点击列表页右上角“Export”按钮）
- 库存显示“❓ 无库存记录”怎么办？（去“库存流水”页，为该药品补录一笔入库）

Day 18晚上10点，系统正式切换。我们守在服务器前，看着/var/log/django/app.log里滚动的200 GET，听着打印机吐出第一张销售小票的沙沙声。那一刻，“Django Saves the Day”不再是口号，而是实实在在的、带着油墨味的现实。

5. 常见问题与排查技巧实录：那些踩过的坑，都成了经验

5.1 数据库迁移冲突：`makemigrations`报错“Conflicting migrations”

现象：团队协作时，A和B同时基于main分支开发，A提交了0001_initial.py，B提交了0001_squashed_0003.py，migrate时报错。

根因：Django的迁移文件名包含时间戳，但多人并行时，时间戳可能相同，导致Django无法确定执行顺序。

解法：

手动编辑B的迁移文件，将dependencies改为[('pharmacy_core', '0001_initial')]
在B的机器上执行：python manage.py migrate pharmacy_core 0001_initial（先回退到A的版本）
再执行：python manage.py migrate（应用B的迁移）

实操心得：救场项目严格采用“主干开发”（Trunk-Based Development），所有人每天至少合并一次代码。禁用Feature Branch。我们用Git Hook在pre-commit阶段自动运行python manage.py makemigrations --check，未生成迁移文件则拒绝提交。

5.2 Admin搜索失效：`search_fields`不生效

现象：在Admin搜索框输入药品名，返回空结果。

排查步骤：

检查search_fields是否包含'name'（注意不是'name__icontains'，那是filter()语法）
检查数据库字段是否为VARCHAR类型（PostgreSQL的TEXT类型也支持）

检查是否启用了pg_trgm扩展（PostgreSQL全文搜索增强）：

CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE INDEX CONCURRENTLY ON pharmacy_core_medicine USING gin (name gin_trgm_ops);

最后检查：settings.py中USE_I18N = True是否开启？关闭它有时能解决奇怪的编码问题。

5.3 Gunicorn启动失败：`Address already in use`

现象：gunicorn报错OSError: [Errno 98] Address already in use。

原因：上次进程没杀干净，端口被占。但更隐蔽的原因是：gunicorn的worker进程崩溃后，父进程没退出，还在监听端口。

速查命令：

# 查看占用8000端口的进程 lsof -i :8000 # 或 netstat -tulpn | grep :8000 # 强制杀死所有gunicorn进程 pkill -f gunicorn # 如果不行，用PID kill -9 $(pgrep -f "gunicorn.*pharmacy_core")

注意：在Docker中，应使用supervisord或systemd管理Gunicorn进程，避免手动启停导致状态混乱。

5.4 时区问题：数据库存的时间比本地时间早8小时

现象：Admin里看到的created_at是2024-01-01 16:00:00，但实际是凌晨。

根因：Django默认使用UTC时区，而你的服务器时区是CST。

正确解法：

settings.py中：

USE_TZ = True # 必须为True TIME_ZONE = 'Asia/Shanghai' # 设置为中国时区

数据库连接参数中，显式声明时区：

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'OPTIONS': { 'options': '-c timezone=Asia/Shanghai' } } }

模型字段用DateTimeField而非DateField，并在auto_now_add时确保时区正确。

5.5 静态文件404：`/static/admin/css/base.css`找不到

现象：Admin页面样式全无，浏览器控制台报404。

原因：Django在生产环境不提供静态文件服务，必须由Nginx或CDN处理。

检查清单：

settings.py中STATIC_URL = '/static/'，STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
运行python manage.py collectstatic --noinput，确认staticfiles/目录下有admin/子目录
Nginx配置中location /static/的alias路径是否指向staticfiles/（注意末尾斜杠）
文件权限：chmod -R 755 staticfiles/

实操心得：救场时，我们用whitenoise作为过渡方案。pip install whitenoise，然后在MIDDLEWARE中加入'whitenoise.middleware.WhiteNoiseMiddleware'，并设置STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'。它能让Django自己服务静态文件，省去Nginx配置，特别适合快速验证。

6. 救场之后：Django如何成为长期伙伴

“Django Saves the Day”不是终点，而是起点。那个药店系统上线半年后，我们已迭代了12个版本：增加了供应商协同平台、接入医保结算接口、上线了AI辅助审方模块。Django的“救场力”，正在转化为“续航力”。

它的长期价值，在于一种克制的优雅。它不承诺解决所有问题，但把90%的通用问题，封装成可预测、可测试、可交接的代码契约。当你需要快速验证一个业务想法时，Django给你一个坚实的地基；当你需要支撑百万级用户时，它清晰的瓶颈告诉你该往哪里加缓存、读写分离、异步队列；当你需要团队协作时，它用models.py、views.py、admin.py的物理隔离，无声地规范着每个人的职责边界。

我见过太多项目，初期用“更灵活”的框架，结果半年后，代码库变成一锅粥，没人敢动核心模块，每次上线都像拆炸弹。而Django项目，哪怕过了三年，新来的工程师看一眼models.py和admin.py，就能大致明白系统在管什么、数据怎么流。这种可维护性，才是技术选型最该珍视的资产。

最后分享一个小技巧：在每个Django项目根目录下，放一个HOW_IT_WORKS.md文件。不用写多深奥，就三句话：