广州it工作第四周

周一：

• 完成租地功能：设计租赁信息表，JWT鉴权后创建租赁记录。
• 注意点： 补充了状态字段设计。

周二：

• 构建订单系统：创建订单主表及详情表，实现：
  JWT用户订单查询
• 多状态分类（待支付/待发货等）
• PageHelper分页（>10自动分页，加载页面缓存进度）

周三：

• 订单详情增强：调用土地接口展示租赁地块信息。
• 前端隐患：this.orderInfo.items[0] 强耦合数据绑定。

周四：

• 订单状态管理：实现增删改查及状态流转（如取消订单同步释放土地）。
• 优化： 采用状态模式替代if-else链。

周五：

• 支付功能受阻：
  致命问题： 后端未配置HTTPS（微信支付强制要求）
• 设计缺陷： 订单号长度不符支付接口规范（20位≠32位）
• 转向： 启动手机号验证方案研究。

周六：

• 微信验证困局：
  手机号快速验证失败（需企业认证）
• getUserProfile仅获取基础信息（头像/昵称）
• 开放数据解密流程复杂且无进展

---

核心卡点：

1. 支付环节： HTTPS缺失 + 订单号设计缺陷
2. 微信生态： 政策收紧导致手机号获取路径封死

一、独立完成 & 挑战 & 成长

事项	独立完成	最大挑战	克服方式	成长
租地系统	租赁表设计 + JWT用户绑定	状态字段缺失	快速补字段 + 关联订单状态	意识到数据扩展性的重要性
订单中台	双表创建 + 分页/状态筛 + 状态机	订单号长度设计不足(20位)	重构为32位 UUID	关键字段需预判业务需求
支付对接	调用微信支付流程开发	1. 无HTTPS
2. 微信政策限制	转向备用方案（手机号验证）	第三方功能必须预研环境/政策
微信集成	实现getUserProfile基础授权	无法获取用户准确信息（政策封锁）	明确放弃，转为人工审核流程	学会在限制中寻找替代路径

---

二、本周工作思考

1. 做得好的
   基础功能闭环：租地→订单→状态流转全链路跑通
2. 快速响应问题：发现订单号缺陷应该立即重构
3. 待改进的
   致命疏忽：支付未提前验证HTTPS/字段规则 → 导致整块功能返工
4. 过度乐观：低估微信政策限制（开发者权限）
5. 核心认知
   “能开发” ≠ “能上线”
   第三方依赖的合规性（HTTPS/政策）比代码更重要

---

三、未来同样机会的做法

1. 预研四象限（首日必做）
   1
   2
   3
   4
   [技术] [政策] [环境] [兼容性] │ │ │ │ ├─HTTPS? ├─微信文档? ├─测试账号? ├─字段长度? └─SDK兼容 └─权限范围 └─域名备案 └─数据格式
2. 设计两原则

字段设计：订单号/金额等支付相关字段，直接对齐微信要求（32位/UUID）
3. 解耦开发：支付模块用模拟运行，便于替换（例：HTTPS未就绪时模拟支付）
4. 政策应对

项目避免强依赖微信敏感接口（如手机号）

总结一句话：
下次先花2小时跑通支付Demo+政策验证，再动手写业务代码。
功能开发速度 ≠ 交付速度，预研省下的就是返工浪费的。