做设备报修管理系统这个项目，起因其实很朴素：公司行政每次收到报修，都在微信群里喊一句“3楼打印机又卡纸了谁去看看”，然后@全员，最后谁修的、修没修好、换了什么配件，全凭记忆。所以当我想做一套“微信小程序 + Django”的设备报修管理系统时，最先想清楚的不是代码，而是这套系统到底要替谁省时间、省什么时间。
这个项目说白了就是一个带前后端分离逻辑的垂直业务系统：微信小程序当用户的手，用来提交报修、拍照上传、查看工单进度；Django 后端当大脑，负责设备台账、报修单流转、维修派单和数据统计。适合正在学 Django 想做点实战项目的人，也适合企业内部想用低成本方案替换“微信群报修”的团队参考。我把整个设计、编码、联调、部署过程中踩过的坑和沉淀下来的方案完整记录下来，希望对你有实际帮助。
1. 项目整体设计与技术选型：先想清楚再动手
1.1 设备报修到底要解决什么问题
很多人在拿到“设备报修管理系统”这个需求时，第一反应是列功能清单：报修、派单、维修、完成。这没错，但不够。我第一轮调研时专门翻了过去三个月公司在微信群里的报修记录，发现真实痛点远不止“记录一条报修”这么简单。
最痛的是两个问题：第一，责任人不明确。一台设备坏了，群里喊半天没人接话，最后往往是行政自己去催；第二，过程不可追溯。设备修完之后，换没换配件、维修人员是谁、下次保养什么时候做，完全没有沉淀。所以我在设计系统时，明确要求后端必须维护三类核心数据：设备台账、报修工单、维修记录。设备台账解决“哪些设备存在、放在哪、归谁管”，报修工单解决“谁报修、什么状态、派给谁”，维修记录解决“修了什么、花了多少、什么时候修的”。
另一个容易被忽略的需求是统计口径。管理层真正关心的不是某个设备修好了没，而是“这个月一共坏了多少台设备、主要集中在哪些类型、平均维修耗时多久”。所以在 Django 模型设计阶段，我就把报修单里的设备类型、故障分类、维修耗时、费用字段都单独抽出来，而不是塞在一个备注字段里。后面写统计接口、导出 Excel 时，就知道当初多花十分钟建模有多么值。
1.2 为什么选微信小程序 + Django，以及 Node.js 在其中扮演的角色
选型时我对比过三个方案：纯网页端、微信小程序、App。最终选了微信小程序，原因非常现实：用户不需要安装 App，微信里直接能用；公司内部有企业微信和微信群，小程序的分享和消息触达正好接得上。你要知道，让每个员工去应用商店下载一个企业内部 App，光这一步就能劝退一半人；但小程序呢，扫个码、转个发，就能直接进来。
Django 作为后端的原因更简单：Django 自带 Admin 后台、ORM、用户认证和 Admin 站点的权限体系，这些对内部管理系统来说天然合适。设备报修这种业务逻辑并不复杂，但数据关系比较多——用户、设备、工单、维修记录、配件清单，Django 的 ORM 能把关系维护得很清楚，而且文档完善，遇到问题搜索成本低。
这里有个很多人不理解的地方：为什么这个项目标题里会出现 Node.js？实际开发微信小程序时，微信开发者工具本身依赖 Node.js 环境来运行编译和模拟器，同时小程序的 npm 构建、第三方组件库编译也要用到 npm 命令。所以本机必须装好 Node.js（推荐 LTS 版本，比如 18 或 20），这是前端开发环节的基础依赖，而不是说用 Node.js 写后端。换句话说，这个项目的技术栈是：小程序原生框架写前端，Django 写后端，Node.js 作为小程序开发工具链的运行时。把这一层关系理清，后续配置环境就不会再犯糊涂。
1.3 整体架构：小程序、API、数据库三层分离
项目整体分三层：微信小程序客户端、Django REST API 服务、MySQL 数据库。小程序端只负责页面交互，不直接连数据库，所有数据操作都通过 HTTP 请求访问 Django 提供的 JSON 接口；Django 端通过 ORM 操作数据库，返回统一格式的 JSON；MySQL 存储设备、工单、用户等结构化数据，同时配合 Django 的 media 目录存放用户上传的报修图片。
这种分层带来的直接好处是：后面如果要加一个 Web 管理端或钉钉端，只需要复用同一套 Django API，不用动小程序代码。我实际开发中也是先写清了 API 契约，再同时让小程序端和后端并行开发。当然这也带来一个必须解决的问题——跨域。小程序开发者工具里勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”才能直接访问本地 Django，真机预览则必须在服务器上部署 HTTPS 接口，这块后面专门讲。
2. 微信小程序端的页面与交互实现
2.1 小程序端四个核心页面的职责划分
页面设计我没有做复杂的 tabBar 结构，而是用四个页面撑起全部业务流程：首页、报修填写页、工单列表页、工单详情页。
首页的定位是入口+概况。顶部放一个当前用户的信息卡片，中间放一个醒目的“我要报修”按钮，下面展示最近 5 条我的报修记录。这个页面的目的就一个：让用户用最少的点击进入到报修流程。
报修填写页是重中之重。字段上我选择了：设备名称（支持从设备台账中模糊搜索）、故障描述（多行文本）、故障类型（下拉选择：硬件损坏/软件问题/网络故障/耗材配件/其他）、紧急程度（单选：普通/加急/紧急）、上传图片（最多 3 张）、联系方式和所在位置。这些字段不是越多越好，而是每个字段都有实际用途：位置信息帮助维修工快速找到设备，紧急程度决定派单时的排序权重。
工单列表页要注意列表加载更多这个细节。初期我做的是全量加载，测试时几十条没问题，但放上真实数据后首屏加载卡顿明显。后来改成“首次加载 10 条，滚动到底部自动加载下一页”的分页模式，这里核心逻辑是记录当前页码 page 和 totalPage，每次请求带上 page 参数，后端返回总页数，前端在 onReachBottom 里判断“如果当前页小于总页数，就继续请求下一页并 append 到列表尾部”。这个逻辑说起来简单，实际写的时候很容易出 bug：一是重复请求，用户快速滚动时会触发多次 onReachBottom；二是数据覆盖，第一次加载把上一页数据覆盖掉了。我的做法是加一个 isLoading 锁，请求进行中直接 return，成功后用 this.setData 把新数组 concat 上去。
工单详情页展示完整状态流：提交时间、当前节点（待派单/维修中/已完成/已取消）、维修结果描述、评价入口。这里有一个小程序导航问题：顶部导航栏高度在不同机型上不一样，如果自定义导航栏，需要按官方推荐的胶囊按钮位置动态计算 height 和 margin-top。我为了省事直接用的默认导航栏，页面标题用navigationBarTitleText配置，省掉不少适配工作。
2.2 报修表单：图片上传与设备信息绑定的关键细节
图片上传这里，我的踩坑经历值得单独说。最初我把图片 base64 编码后放进 JSON 里传给 Django，测试小程序端完全正常，但一旦图片稍微大一点（比如手机拍出来 2MB 的照片），请求体积直接爆掉，上传慢还经常超时。后来改成先调用wx.uploadFile上传图片文件到 Django 的/api/upload/接口，拿到返回的图片 URL，再在提交报修单时把 URLs 作为数组字段传给后端。这是一个典型的上传策略选择：报修单的文本信息和图片文件分开传输，各自处理，错误定位也清晰。
多图上传的并发控制也很关键。wx.uploadFile 支持单张上传，多张图不能一次性传，我用Promise封装了一个顺序上传的方法：循环遍历图片临时路径列表，每次 await 单张上传完成后再发起下一张，最后把所有 URL 汇总。顺序上传比Promise.all并发上传慢，但胜在稳定，不容易把服务器文件接口打崩。
设备信息绑定方面，我做了个小优化：报修页允许用户直接手动输入设备名称，但更推荐从设备台账列表里选择。前端通过一个搜索框调用后端接口，输入关键字实时匹配设备名称和位置，选中后自动填充设备 ID、所属区域和设备类型。这个交互的好处是：报修单上自动带上设备唯一 ID，Django 后端可以直接关联到设备表，统计哪台设备故障次数最多时就非常轻松，不用靠设备名称去字符串匹配。
2.3 请求封装、登录态与全局状态管理
小程序端我建了一个utils/request.js，统一封装wx.request。每个请求都要带上 header，我用Authorization: Token ${token}来标识用户身份。Django REST Framework 用的是 TokenAuthentication，用户在第一次打开小程序时调用wx.login获取临时 code，然后把 code 传给后端的/api/auth/login/接口，后端拿着 code 调用微信的jscode2session接口换取 openid，再查库或创建用户，最后生成 token 返回小程序。小程序端把 token 存在wx.setStorageSync里，后续所有请求都自动带上。
全局状态管理我没有引入第三方库，而是用小程序原生的getApp().globalData存了一个 userInfo 对象。小程序页面之间跳转传参比较复杂，用 globalData 存当前用户和最近的报修草稿，比每次页面 onLoad 时重新读 Storage 更高效。但要注意，小程序冷启动时 globalData 会重建，所以关键数据（比如登录 token、用户 openid）必须同步持久化到 Storage，页面启动时先读 Storage，再考虑更新 globalData。
登录态还有一个容易踩的坑：token 过期问题。Django 的 Token 默认不过期，但如果用户换设备登录、或者后台手动清数据，token 就会失效。我在 request.js 里做了一个统一响应拦截：如果返回码是 401，就清掉本地 token，跳转回首页并提示用户重新进入。这个拦截逻辑要在所有接口的最外层统一处理，而不是每个页面单独判断，否则很容易漏。
3. Django 后端 API 与数据模型设计
3.1 应用拆分与模型字段设计
Django 项目我建了三个 app：accounts（用户与登录）、equipment（设备台账）、repair（报修工单与维修记录）。之所以拆成三个 app 而不是塞进一个core里，是为了让每个 app 的 responsibility 清晰，后面扩展时不会牵着葫芦动了瓢。比如未来要加“资产盘点”，直接在 equipment app 里加模型和接口，不影响 repair 的逻辑。
用户模型我用的不是直接替换 Django 自带的 User 模型，而是创建一个Profile模型和 User 一对一关联。里面有 role 字段（user/repairer/admin）、姓名、手机号、openid。为什么不用 openid 当主键？因为系统未来可能在 Web 端开放账号注册，不能把登录方式绑死在微信上。openid 作为 User 关联 Profile 的一个唯一字段即可。
设备模型设计得相对完整：
| 字段 | 类型 | 说明 |
|---|---|---|
| name | CharField | 设备名称 |
| device_type | CharField | 设备类型（打印机/投影仪/电脑/网络设备/其他） |
| location | CharField | 所在位置，如“3楼会议室” |
| status | CharField | 正常/维修中/报废 |
| owner | ForeignKey(User) | 设备管理员 |
| purchase_date | DateField | 购置日期 |
| price | DecimalField | 资产价值（可选） |
报修工单模型是核心，我把关键状态字段单独列出来：status用 CharField + choices 实现，取值包括pending（待派单）、processing（维修中）、completed（已完成）、cancelled（已取消）、rejected（已驳回）。加上device（ForeignKey 到设备）、reporter（ForeignKey 到 User）、assignee（维修人员）、fault_type故障类型、description、image_urls（JSONField 存图片 URL 列表）、priority（紧急程度）、created_at、finished_at。
这里我特别建议：Django 3.1 以上用 JSONField 存图片 URL 列表，比建一张报修图片子表更省事。如果你一定要建子表也行，但那意味着每次查报修单要带出子表数据，API 序列化和页面渲染都会多一层嵌套，没必要。
3.2 Django REST Framework 接口规范
我引入了 DRF（Django REST Framework）来写接口，没有手写 JSONResponse。DRF 提供了几件事：序列化器（ModelSerializer 直接从模型生成字段）、视图集（ViewSet）和路由注册（Router）、认证与权限控制。核心接口列表如下：
| 接口 | 方法 | 功能 |
|---|---|---|
| /api/auth/login/ | POST | code 换 token |
| /api/equipment/ | GET | 设备列表（支持 keyword 搜索） |
| /api/repairs/ | GET/POST | 我的报修单列表/发起报修 |
| /api/repairs/{id}/ | GET | 工单详情 |
| /api/repairs/{id}/status/ | PATCH | 修改状态（派单/完成/取消） |
| /api/upload/ | POST | 图片上传 |
| /api/stats/ | GET | 报修统计 |
每个接口的返回格式我保持了统一：{ "code": 0, "data": ..., "message": "ok" }。DRF 默认的返回格式不是这个，我在项目里写了一个renderer.py，重写finalize_response把 data 包一层。这样做的好处是小程序前端不需要在每个页面写 try-catch 解析异常结构。后来的运维经验也证明，统一响应结构在排查问题时更快：看到 code 不等于 0，直接看 message 就能定位。
关于序列化器，要重点关注嵌套关系。报修单列表里需要显示设备名称和报修人姓名，如果直接 Serializer 嵌套 User/Device 模型，会导致列表接口查询量大增。我做了一层简单的序列化，在报修单的 Serializer 里用SerializerMethodField返回device_name和reporter_name，而不是嵌套整个对象。这样列表请求返回体小，前端渲染快。
3.3 Django 查询与删除对象的三种常用写法
这个项目里最常用的数据操作就是查询报修单和删掉错误数据。我整理一下 Django 执行查询和删除的常见方式，新手照着用不会乱。
查询方面，最基础的是RepairOrder.objects.filter(reporter=user, status='pending')，返回一个 QuerySet。如果你只想要一条记录，要加.first()或者用get，但get在没有记录时会抛DoesNotExist异常，所以我更推荐filter().first()这种写法，返回 None 而不是抛错，代码更稳。
多条件组合查询有一个坑：多个filter链式调用是 AND 关系，不要试图把一个条件里的“或”逻辑写错。比如“查待派单或维修中的工单”，正确写法是Q(status='pending') | Q(status='processing')，导入from django.db.models import Q。新手最容易在这里踩坑，写成filter(status=['pending', 'processing'])直接报错。
分页查询我用的 DRF 的PageNumberPagination，直接在 Settings 里配置PAGE_SIZE，并在视图中设置pagination_class。前端传page参数，后端返回{count, next, previous, results}。这里要注意 DRF 的响应键名是results而不是data，小程序端解析时要对应上。
至于删除对象，按危险程度从低到高有三种方式：
order.delete()：单条删除，最推荐，ORM 会触发信号和级联。RepairOrder.objects.filter(id=id).delete()：批量删除接口，返回的是删除条数，不触发信号。order.soft_delete()：这个是我自建的逻辑，更安全。实际管理系统中我不建议物理删除报修单，因为报修数据是要做统计的。正确做法是给模型加一个is_active字段，逻辑上屏蔽，而不是直接从库里删。
我在项目里把“删除”接口做成了 PATCH，只把is_active改成 False，列表接口默认过滤掉。这样管理人员误操作还能恢复，统计报表也不会缺数据。
4. 核心业务流程：从报修提交到工单闭环
4.1 工单状态机的设计与实现
设备报修系统最核心的东西不是 CRUD，而是状态流转。我把状态机简化成五个节点，并用白纸画出来再编码：
pending（待派单） → processing（维修中） → completed（已完成） ↓ | cancelled（已取消） ↓ rejected（已驳回）流转规则是：用户提交后进入 pending；管理员将工单指派给维修人员时变为 processing；维修工完成维修、填写结果后变为 completed；提交后管理员也可以驳回或取消（比如设备已经报废、不需要修了）。
实现上我没有用单独的 django-workflow 之类的库，直接在RepairOrder模型里写了一个transition_status(new_status, user)方法，内含所有校验逻辑。比如：只有admin角色能执行“派单”动作，completed状态只能由维修人员本人操作，且前置状态必须是processing。这样把规则收在模型层，视图和序列化器都变薄，不容易出现“谁都能改状态”的权限漏洞。
4.2 三种角色的权限控制方案
系统里有三种角色：普通用户、维修人员、管理员。DRF 的权限控制我用了两层：认证层IsAuthenticated保证所有接口必须登录；业务层自写IsRepairerOrAdmin等权限类，判断请求用户角色。
具体到报修单的操作权限：
- 普通用户：只能创建报修单、查看自己创建的报修单、取消未开始的工单。
- 维修人员：能查看分配给自己的工单、修改工单状态为维修中/已完成、填写维修结果。
- 管理员：能查看所有工单、分配工单、驳回/取消、修改设备台账、查看统计报表。
权限控制是内部系统里最容易出安全问题的角落。我之前见过一个系统，普通用户通过接口直接把工单指派给其他人，就是因为后端没有校验角色。我的习惯是：前端按钮隐藏只是体验优化，后端接口权限校验才是真正的安全边界。每个接口处理业务逻辑前，必须显示地判断request.user.profile.role，不能依赖前端传的角色字段。
4.3 消息通知：小程序订阅消息与站内通知
维修工单流转过程中，用户最关心的是“我报修的东西有人处理了吗”。我实现了两种通知：
站内通知是最简单也最稳的方案。Django 端有一个Notification模型，字段包括user、content、is_read、created_at。每次工单状态变化时，在 transition 方法里自动创建一条通知记录，小程序端在“我的消息”里拉取未读数。这个方案零成本、无延时，非常适合内部系统。
小程序订阅消息是增强方案，但这里要泼一盆冷水：订阅消息不是你想发就能发的。微信规定用户每次在页面上主动点击“允许订阅”后，开发者才能下发一条模板消息，一次性订阅不能长期保留。所以我在提交报修成功的页面上放了一个“接受维修进度通知”的按钮，用户点一下，我记录one_time_subscription的 token，后续状态变化时尝试下发一条订阅消息。用户如果没点，那就只发站内通知，绝不对未授权用户调用订阅消息接口，否则会报 43101 错误。
5. 环境配置、联调与部署
5.1 本地开发环境清单：Node.js、微信开发者工具、Python/Django
开发这套系统，本地环境有五样东西缺一不可：
- Python 3.10+，安装 Django 4.x 和 djangorestframework。
- 微信开发者工具稳定版，用于打开小程序工程并调试。
- Node.js 18 LTS 以上。微信开发者工具在编译小程序时，内置的 npm 构建能力需要调用 Node.js 环境。如果你在小程序项目里用了 npm 包（比如 vant-weapp 组件库），还需要在项目根目录执行
npm install，然后通过开发者工具的“工具-构建 npm”生成miniprogram_npm目录。 - MySQL 8.0（或 SQLite 先顶着）。本地开发我用 SQLite，联调没问题，但上线前建议切 MySQL，避免 SQLite 的并发写入问题。
- Git，用于管理小球两端的代码仓库。
这里要重点说 Node.js 的安装细节：直接去 Node 官网下载 LTS 安装包，双击安装时记得勾选自动添加到 PATH。安装完成后在终端执行node -v验证。Windows 上经常出现一个报错：npm : 无法加载文件 ...npm.ps1，因为在此系统上禁止运行脚本。这个问题的根源是 PowerShell 的执行策略默认禁止运行.ps1脚本，解决方案是在 PowerShell 里执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，然后重开终端。这不影响系统安全，只是允许本地的签名脚本运行，不会把远程不受信任的脚本放开。
5.2 小程序与 Django 本地联调的三个先决条件
本地联调时最容易卡住的不是后端逻辑，而是小程序网络请求的环境限制。你需要同时搞定以下三件事：
第一，在微信开发者工具的“详情-本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。这样 HTTP 请求才能访问本地的http://127.0.0.1:8000。如果不勾选，小程序直接报“url not in domain list”。
第二，Django 的ALLOWED_HOSTS必须允许访问。默认是空列表，本地跑没问题，但如果你用电脑的局域网 IP 地址（比如手机真机预览时访问http://192.168.1.100:8000），需要在ALLOWED_HOSTS里加上这个 IP。另一个方案是直接设置ALLOWED_HOSTS = ['*']，但仅限开发，上线必须改为具体域名。
第三，解决跨域。虽然在小程序里没有浏览器的同源限制，但在开发者工具里有些场景还是会被跨域卡住。我安装的是django-cors-headers，在INSTALLED_APPS注册、Middleware中加入CorsMiddleware，并设置CORS_ALLOW_ALL_ORIGINS = True（仅开发环境）。如果上线，则要改成CORS_ALLOWED_ORIGINS白名单。
5.3 Linux 服务器上的 Django 部署与媒体文件处理
正式部署我采用的是经典方案：Nginx + Gunicorn + MySQL。Nginx 负责接收外部请求、代理到 Gunicorn 的 8000 端口，并负责托管静态文件和用户上传的媒体文件。Gunicorn 负责跑 Django 应用。Django 端用collectstatic把静态资源收集到指定目录，media 目录则直接暴露为 Nginx 的/media/路径。
这里有一个开发者容易忽略的问题：Django 默认只处理请求逻辑，不负责图片文件的高并发读取。报修图片上传后如果直接让 Django 自己 serve，流量一上来就扛不住。正确做法是：图片上传接口负责把文件保存到MEDIA_ROOT，而访问图片 URL 时由 Nginx 直接返回文件内容，不经过 Django。这个切换需要在 Nginx 配置里加一个 location 规则：
location /media/ { alias /var/www/repair_system/media/; expires 7d; }小程序端wx.uploadFile上传后的图片 URL 返回的是相对路径，前端拿到后拼上 HOST 就能访问。如果图片加载慢，优先检查 Nginx 的client_max_body_size是否设置了合理值（比如 10M），否则大图片上传会直接返回 413 错误，前端表面看起来是上传失败，实际上请求根本没到 Django。
6. 常见问题与排查技巧实录
6.1 npm.ps1 无法加载：PowerShell 脚本执行策略问题
这个报错文本我见得太多了：npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本。很多新手以为自己 Node.js 安装坏了，重装了好几遍也没用。其实问题根本不在 Node.js，而是 PowerShell 出于安全策略默认不执行.ps1脚本。
解决办法：以管理员身份打开 PowerShell，执行：
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser然后输入Y确认。这个命令的效果是允许本地创建的脚本运行，但来自网络的未签名脚本仍然需要签名才能运行，是安全性相对均衡的方案。如果你的电脑是公司统一管理的域环境，可能还需要联系管理员调整组策略。
另一件相关的事：如果你用了 nvm-windows 切换 Node.js 版本，装了新版 Node 后 npm 找不到，多半是环境变量 PATH 里还有旧版本 Node 的残留路径。检查C:\Program Files\nodejs是否指向当前版本，必要时手动删掉旧路径。
6.2 小程序 request 合法域名报错
在开发者工具里明明接口通着，真机预览时却始终报url not in domain list，这是小程序团队踩坑率最高的问题之一。原因是开发者工具“不校验合法域名”的设置只对工具内的模拟器生效，真机预览走的是微信客户端，微信客户端会对所有 request 请求做域名合法性校验。
排查思路如下：
- 开发调试阶段：微信开发者工具右上角“详情-本地设置-不校验合法域名”。
- 真机预览阶段：在“小程序管理后台-开发-开发设置-服务器域名”里把
https://你的域名加到 request 合法域名白名单。注意必须是 HTTPS，且域名需要备案。 - 如果只是临时给客户看看效果，可以用“开发版/体验版”配合真机调试，但仍需要把域名加进白名单。
个人开发者做这种内部系统，如果不想走认证和域名备案流程，另一个实用方案是：用内网穿透工具临时映射一个域名，配合开发者工具的“真机调试”功能来验证。但正式上线还是建议老老实实走备案流程，微信小程序认证费用一年为 300 元（个人主体开通认证时），这些成本要在项目启动阶段就算清楚。
6.3 Django 跨域问题与 CORS 排查
联调阶段遇到过Access-Control-Allow-Origin缺失的报错。虽然小程序原生的 wx.request 不像浏览器一样强制 CORS，但有时在开发者工具里配合其他调试插件（比如某些抓包工具）时，请求会被拦截或改写，这时候 CORS 配置就必须正确。
我推荐在 Django 中用django-cors-headers，配置起来只需要三步：安装、加入 INSTALLED_APPS、加入 MIDDLEWARE。注意中间件的顺序有讲究，CorsMiddleware要尽量放在列表靠前位置，最好在CommonMiddleware之前。如果发现配置了还是报跨域错，先确认是不是缓存问题：浏览器或微信客户端缓存了旧的响应头，清缓存后再试。
还有一点：如果使用了 Charles 或 Fiddler 抓包调试小程序，电脑上所有流量会走代理，Windows 上如果代理未配置好，会导致 Django 请求能进来但响应异常。这个问题排查起来比较隐蔽，我当时的经验是：先断开 Charles 抓包，如果接口恢复正常，那就是代理导致的，去查看代理规则是否需要排除本机地址。
6.4 图片上传成功但列表不显示
这种问题在本地开发环境能复现，但真机才出现，排查顺序一般是：后端有没有成功存文件 → 数据库里的 URL 字段是否拼对了 → 前端渲染时的 base URL 是否一致。
我遇到的一个典型错误是：本地开发 Django 返回的图片 URL 是/media/upload/xxx.jpg，小程序端拿到这个相对路径后拼上了开发环境的 HOST（比如http://127.0.0.1:8000），图片正常显示。上线后，小程序端着云服务器，但 HOST 还是写死在代码里的本地地址，图片自然加载不出来。
对应的坑位是前端不要硬编码 HOST。我在小程序项目的config.js里维护了一个BASE_URL常量，按development/production环境区分。切换环境时只改这一个文件，页面里所有图片 URL 都由这个 BASE_URL 拼接。另外，上传后的文件名如果用的是时间戳+随机数拼接，要避免中文名和特殊字符，保存文件前用 Django 的FileExtensionValidator做一下扩展名校验，防止用户上传一个带脚本的文件名。
6.5 Django 时间显示和时区问题
时间问题很小，但很多新手都会踩。Django 的TIME_ZONE默认是 UTC，如果直接在模型里存DateTimeField(auto_now_add=True)，存进数据库的时间比北京时间慢了 8 小时。这不影响数据完整性，但在小程序上展示给用户看就会出现“提交时间比当前时间晚 8 小时”。
我的做法是：Django Settings 里设置TIME_ZONE = 'Asia/Shanghai'、USE_TZ = False。对于内部管理系统，不需要跨时区协作，关闭 USE_TZ 可以让时间存储和展示完全一致，省去前端转换的麻烦。注意这里USE_TZ = False是反常规的做法，但适用场景确实存在。如果你需要支持多时区用户，那就应该保持USE_TZ = True，并在 Django 返回 JSON 时统一使用 ISO 8601 带时区偏移的字符串，由小程序端new Date()自动转换成本地时间。
另外，统计报表里的“本月报修数量”，如果直接比较created_at字段要注意日期边界。我写统计接口时，刻意使用timezone.localdate()来计算当天的开始时间和结束时间，而不是用datetime.now()裸拼字符串，避免因为时区再次踩坑。
7. 写在最后：个人实操体会
这套系统我从需求梳理、原型设计到前后端联调、服务器部署，前后花了两周左右，其中真正写代码的时间只占一半，剩下的一半几乎都耗在环境配置和联调排查上。做完之后我最大的体会是：管理系统的核心不是界面多漂亮，而是状态机的严谨和权限控制的完整。用户能看到的只是“提交-等待-完成”，但后端每一步流转的条件、每个角色的操作边界，才是真正决定这套系统靠不靠谱的地方。
如果你打算自己在公司内部复刻一个类似的系统，我给三个建议：第一，先从一张纸画清楚状态机开始，别一上来就写代码，状态流转想清楚能省一半返工时间；第二，权限控制一定要做在后端接口层面，前端隐藏按钮只是体验优化，不是安全屏障；第三，本地开发可以先 SQLite + 不校验域名跑通全流程，再切 MySQL、再部署，阶段划分清楚能少混入很多无意义的问题。
最后再分享一个小技巧：用 Django Admin 给管理员做后台审核界面，几乎零成本就能拥有一个 Web 端的工单管理页面。我给维修人员和管理员都开通了 Admin 站点权限，维修人员只需要在小程序处理工单，而管理员在电脑上打开 Admin 就能完成所有数据修正和派单操作，这两者双轨并行，体验比单独做一套 Web 后台舒服得多。设备报修系统这个方向其实还有不少扩展空间，比如把报修数据接入企业微信告警、加上备件库存管理，底层这套“小程序 + Django”的骨架基本不用动，直接往上叠业务就行。
