广州it工作第四周

周一：

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

周二：

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

周三：

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

周四：

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

周五：

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

周六：

• 微信验证困局：
  • 手机号快速验证失败（需企业认证）
  • getUserProfile仅获取基础信息（头像/昵称）
  • 开放数据解密流程复杂且无进展
• 结论： 当前微信政策下，获取手机号一键登录不可行。

---

核心卡点：

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

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

---

二、本周工作思考

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

   “能开发” ≠ “能上线”
   第三方依赖的合规性（HTTPS/政策）比代码更重要

---

三、未来同样机会的做法

1. 预研四象限（首日必做）

   1 2 3 4

   [技术] [政策] [环境] [兼容性] │ │ │ │ ├─HTTPS? ├─微信文档? ├─测试账号? ├─字段长度? └─SDK兼容 └─权限范围 └─域名备案 └─数据格式

2. 设计两原则

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

3. 政策应对

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

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