广漂码农第三周

核心目标： 独立搭建农场小程序的订单系统（包括后台接口、前端页面和数据库）。

本周主要进展：

1. 项目启动与基础搭建 (周一)：

   • 用开发工具创建了小程序项目框架。
   • 首页： 实现了图片热区点击跳转（用绝对定位精确定位点击区域，uni.switchTab跳转底部菜单页）。
   • 公告栏： 暂时留空。
   • 我的农场： 开始设计核心玩法（比如种植收获逻辑）。
   • 个人中心： 画好了页面布局。
   • 图片上传到图床，减小小程序安装包体积。

2. 界面优化与农场互动 (周二)：

   • 首页： 用媒体查询让页面在不同尺寸手机上都好看（响应式布局）。
   • 我的农场： 用Grid网格布局做了9块整齐的地块。点击地块能弹出操作图片（比如选择种子）。
   • 个人中心： 本想做微信一键登录（获取手机号），但个人小程序权限不够。改用方案：用户授权获取微信头像和昵称绑定账号，登录成功后服务器返回一个token（身份令牌）存起来，代表用户已登录。

3. 新增功能模块 (周三)：

   • 首页： 加了“马克农场”入口，点击后跳转新页面（用uni.navigateTo页面跳转）。
   • 个人中心： 增加了“设置”页面，可以修改个人信息。

4. 核心登录功能实现 (周四)：

   • 个人中心：
     • 实现了完整的微信登录流程：
       1. 小程序获取临时登录凭证code。
       2. 把code发给我的后台服务器。
       3. 后台用code向微信服务器换取用户的唯一标识(openid)等信息。
       4. 后台查数据库：如果是新用户，就创建账号；老用户则读取信息。
       5. 后台生成token，连同用户信息一起返回给小程序。
       6. 小程序把token和用户信息存起来（storage），后续操作代表该用户。
     • 注：等小程序主体是企业后，可升级为手机号直接登录。
   • 订单页： 实现了跳转到不同订单类型页的功能（在链接后面加?type=...传参）。解决了引入图标库时的兼容性问题。

5. 用户信息保护与更新 (周五)：

   • 完善登录后的安全措施：采用JWT令牌进行鉴权（验证身份）。
     • 为什么选JWT？ 主要因为它不需要Cookie，避免了跨域(CORS)问题，更方便不同服务器间协作。而且服务器不用存储用户登录状态（无状态），减轻负担。
     • 怎么用？ 用户登录后拿到JWT token（就是周四的那个token）。当用户想修改头像昵称等需要登录的操作时，小程序在请求头里带上这个token（格式：Authorization: Bearer <你的token>）。后台收到请求后，先验证token是否有效且合法，验证通过了才允许修改用户信息。
   • 实现了登录后修改头像和昵称的功能。

简单来说，这周： 搭好了小程序的基础架子，重点实现了用户登录注册流程（包括微信授权、后台验证、生成令牌JWT），完成了个人中心的主要功能（信息展示、设置、头像昵称修改），并开始为订单系统做跳转准备。技术上解决了图片优化、布局适配、登录授权、身份验证（JWT）等关键点。

以下是对本周工作的结构化复盘总结，结合实践与成长思考：

---

一、独立完成事项 & 挑战与成长

完成内容	挑战	克服方式	带来的成长
1. 用户系统全流程搭建 - 微信登录+JWT鉴权 - 头像/昵称修改功能	• 个人小程序无法直接获取手机号 • JWT无状态鉴权首次实战	• 改用 Code→OpenID→Token 替代方案 • 研读JWT机制，设计 Bearer Token 请求头鉴权逻辑	✅ 掌握受限条件下的灵活架构能力 ✅ 理解无状态认证的设计优势与风险
2. 农场交互核心模块 - Grid九宫格布局 - 地块点击弹窗交互	• 动态弹窗与地块操作状态联动 • 多端样式适配	• 用 CSS变量+媒体查询 控制响应式 • 事件委托 统一管理地块点击逻辑	✅ 强化 复杂交互前端设计能力 ✅ 提升 CSS3实战应用水平
3. 项目基建优化 - 图床节省包体积 - 路由传参统一管理	• 图标库兼容性问题 • 路由跳转类型混乱	• 源码调试+强制样式覆盖 解决依赖冲突 • 封装 路由工具函数 统一处理?type=参数	✅ 学会 第三方库问题排查技巧 ✅ 养成 提前封装工具类 的习惯

---

二、本周工作思考

1. 技术决策的价值：

选择JWT不仅解决了跨域问题，更让我意识到技术选型需服务业务场景——个人小程序无法用企业级登录方案时，用Token机制快速搭建安全认证体系是最优解。

2. 限制催生创新：

微信API权限限制反而推动设计出更通用的 「Code+OpenID+DB」用户绑定流程，未来扩展手机号/邮箱登录只需复用该流程。

3. 技术债预警：

临时解决CSS兼容性的“hack手段”需在迭代中重构，开发效率与代码质量必须动态平衡。

---

三、若重来我会如何做？

1. 前置设计更彻底：

• 用流程图预先规划登录/鉴权全链路（避免周四返工）
• 订单系统数据库提前预留扩展字段（如order_type应对跳转传参）

2. 技术方案分层验证：

• 关键模块（如JWT）先写技术原型Demo再集成
• 第三方库（uView）提前做兼容性测试矩阵

3. 自动化提效：

• 用CI/CD工具自动压缩图片上传图床
• 编写路由配置生成脚本避免手写跳转参数

总结：未来需更注重前瞻性设计与可持续架构，让代码既能跑得快，更能跑得远。