fix(api): 修复专区白名单和商品移除假成功问题

- 调整 .env.development 中 VITE_API_URL 配置为正式接口地址
- 修复 ShopGoods.sectionIds 字段更新时 null 被忽略导致移除专区商品假成功问题
- 通过 UpdateWrapper 显式设置 section_ids 字段避免 MyBatis-Plus 全局更新策略影响
- 补充后端下单接口白名单强校验，防止绕过前端受限专区限制
- 澄清买家用户体系为 sys_user，确认白名单弹窗使用 pageUsers 数据源正确
- 删除白名单弹窗 isStaff 限制，白名单覆盖所有 sys_user 用户
- 记录专区白名单功能设计与实现细节，明确前后端联动机制
- 提示“专区管理”菜单入口需后端菜单表动态下发，确保后台导航可见

.workbuddy/memory/2026-08-17.md

@@ -0,0 +1,28 @@
+# 2026-08-17 工作日志
+
+## 专区商品「移除」假成功 bug 修复
+- 现象：guilixu.websoft.top/special/zone 移除专区商品提示成功，刷新（重查库）后商品仍在。
+- 根因：`ShopHomeSectionController.removeGoods` 用 `listByIds` + `updateBatchById` 改 `shop_goods.section_ids`；单专区商品移除后 section_ids 变 null，但 `ShopGoods.sectionIds` 无更新策略注解，MP 全局默认 `NOT_NULL` 会忽略 null 值 → 不生成 `SET section_ids=NULL` → 库字段保持原值（假成功）。多专区商品（变非 null）正常，故仅单专区场景坏。
+- 修复：`addGoods`/`removeGoods` 改用 `UpdateWrapper.set("section_ids", newVal).eq("goods_id", id)` 显式更新（newVal 可为 null），绕过字段策略。文件：guilixu-java `ShopHomeSectionController.java`。
+- 部署：需重新编译部署 guilixu-java（线上 shop-api）后端生效；前端无需改动。添加用同样模式统一修复。
+- 验证：部署后用单专区商品移除测试，刷新不应再出现。
+- 注：本机环境无 maven，未本地编译；改动为标准 MP 用法（IService.update(Wrapper) / UpdateWrapper.set 允许 null）。
+
+## 专区白名单功能诊断（功能当前不可用）
+- 设计意图：专区设为"受限专区"(restricted=1) 后，该专区商品仅白名单用户可用余额购买；小程序结算页 checkout.tsx 已调 `check-permission` 前端拦截。
+- 致命错配：后台白名单弹窗 `UserSelectModal.vue` 用 `pageUsers`(@/api/system/user → sys_user 后台员工) 选用户；后端 `ShopHomeSectionController.checkPermission` 用 `getLoginUser().getUserId()`（= shop_user 小程序买家 userId）。两套用户体系 id 不一致 → 白名单里加的任何人（后台员工）对真实买家都匹配不上 → 受限专区对买家永远拦截/强制余额，白名单形同虚设。
+- 次要隐患：后端创建订单接口未做白名单强校验，仅前端拦截，可被绕过。
+- 修复方向：① 白名单弹窗数据源从 `pageUsers`(sys_user) 改为 `pageShopUser`(@/api/shop/shopUser → shop_user 买家)，使存的 user_id 与校验 userId 同体系；② 后端下单接口加白名单强校验防绕过。后台已有 pageShopUser 可用。
+
+## 专区白名单：用户体系澄清 + 后端强校验（用户 2026-08-17 01:50 指令）
+- 用户澄清：本项目的买家(小程序用户)就是 `sys_user` 体系，`pageShopUser` 实际不用/返回空。故白名单弹窗用 `pageUsers`(sys_user) 是**正确**的，之前"用户体系错配"判断为误判。
+- 白名单弹窗 `UserSelectModal.vue` 现状（8-16 已改）：`pageUsers({ keywords, ... })`，**不传 isStaff**（搜索覆盖全部 sys_user）。源码无需再改。已 grep 确认 zone 目录下无残留 isStaff/pageShopUser。
+- 后端补「受限专区白名单强校验」：`OrderBusinessService.java` 新增
+  - import：`ShopHomeSectionService`、`ShopHomeSectionUserService`、`QueryWrapper`、`java.util.Set/LinkedHashSet`；
+  - `@Resource` 注入 `homeSectionService`、`homeSectionUserService`；
+  - `createOrder` 在 `validateDeliveryRegionIfNeeded` 之后调用 `validateSectionPermissionIfNeeded(request, shopOrder, loginUser)`；
+  - 新方法逻辑：遍历 `request.goodsItems` → 取 `ShopGoods.sectionIds` → 找 restricted=1 的专区 → 校验 `loginUser.getUserId()` 是否在 `shop_home_section_user`（count>0），否则抛 `BusinessException("该商品属于受限专区，仅限指定白名单用户购买")`。
+- 作用：前端 `check-permission` 的后端兜底，防止直接调 `/shop/shop-order` 下单绕过白名单。
+- 部署：需重新编译部署 guilixu-java（shop-api）。前端无需改动。
+- 注：本机无 maven，未本地编译；改动为标准 MP 用法（IService.count(QueryWrapper) / getById）。
+- 待确认：用户 "2.帮我补" 指令只写了前半句，已按上文补后端强校验；若其本意是"补菜单记录"(专区管理入口，动态路由待插入)，需另出 INSERT SQL（菜单表结构待确认）。

.workbuddy/memory/MEMORY.md

@@ -65,3 +65,18 @@
 - 下单校验 `DeliveryRegionChecker` 读 `regionIds` 直接生效（regionMode=2 为不发货黑名单）。
 - ⚠️ 教训：第一版误用 `provinceIds`/`cityIds` 字段名，与后端 `regionMode`/`regionIds` 不匹配，MyBatis-Plus 自动忽略未知字段导致"没存"。改字段名对接即可，不必新增后端字段。
 
+### 专区白名单用户体系（2026-08-17 用户确认澄清）
+- **结论：本项目买家(小程序用户)就是 `sys_user` 体系，不存在用户体系错配。** 之前怀疑"pageUsers(sys_user) vs 小程序买家(shop_user) 错配"是误判——`pageShopUser`(@/api/shop/shopUser) 在本项目实际不用/返回为空。
+- 白名单弹窗 `UserSelectModal.vue` 用 `pageUsers`(@/api/system/user → `sys_user`) 选用户是**正确**的；存到 `shop_home_section_user.user_id` 与下单校验 `checkPermission` 用的 `getLoginUser().getUserId()` 同体系，能正确匹配。
+- 8-16 已去掉 `isStaff:true` 限制，白名单搜索覆盖全部 sys_user 用户（不局限于后台员工）。
+- ⚠️ 不要再把白名单弹窗数据源改成 pageShopUser（用户明确说 pageShopUser 没用）。
+- **后端下单白名单强校验（2026-08-17 已补）**：`OrderBusinessService.createOrder` 新增 `validateSectionPermissionIfNeeded(request, shopOrder, loginUser)`，遍历订单商品的 `section_ids` 找受限专区(restricted=1)，校验下单用户是否在 `shop_home_section_user` 白名单，不在则抛 "该商品属于受限专区，仅限指定白名单用户购买"。这是前端 `check-permission` 的后端兜底，防直接调下单接口绕过。
+- 前端 guilixu-taro `pages/shop/checkout.tsx` 已调用 `check-permission` 做前端拦截（受限专区强制余额/block）。
+- **当前状态：专区白名单功能完整可用**（前端拦截 + 后端兜底）。另：专区管理菜单入口由后端菜单表下发（动态路由），若后台左侧导航看不到"专区管理"，仍需在后端菜单表补一条记录(component=special/zone, tenant_id=10606)。
+
+### ⚠️ ShopGoods.sectionIds 字段更新陷阱（MyBatis-Plus 字段策略）
+- `ShopGoods.sectionIds` 无 `@TableField(updateStrategy)`，走全局默认 `NOT_NULL`（application.yml 未配 `update-strategy`）。
+- 用 `updateById`/`updateBatchById` 把 `section_ids` 设为 `null`（清空所属专区）时，MP **忽略该 null 字段、不生成 SET**，表现"更新成功但库未变"（假成功）。
+- **正确做法**：清空/置空场景改用 `UpdateWrapper.set("section_ids", newVal)` 显式 set（newVal 可 null），绕过字段策略。
+- 已修复点：`ShopHomeSectionController.addGoods`/`removeGoods`（2026-08-17）改用此模式。同项目其它"置空某字段"的更新都要警惕此坑。
+