104 lines
3.1 KiB
Markdown
104 lines
3.1 KiB
Markdown
# 字段映射问题诊断和验证
|
||
|
||
## 🔍 问题分析
|
||
|
||
根据您提供的数据，当前API返回：
|
||
- `supplierName`: "16666666666" (手机号)
|
||
- `buyerName`: "17777777777" (手机号)
|
||
- `fundName`: "17777777771" (手机号)
|
||
|
||
这说明我们的关联查询逻辑可能没有正确执行。
|
||
|
||
## 🔧 已实施的修改
|
||
|
||
### 1. 后端修改
|
||
- ✅ 修改了 `DeliveryServiceImpl.pageQuery` 方法
|
||
- ✅ 添加了 `MemberMapper.selectMemberUserById` 方法
|
||
- ✅ 实现了 `member` 表和 `member_user` 表的关联查询
|
||
- ✅ 添加了详细的调试日志
|
||
|
||
### 2. 前端修改
|
||
- ✅ 实现了回退机制：`row.supplierName || row.supplierMobile || ''`
|
||
|
||
## 🧪 验证步骤
|
||
|
||
### 1. 检查后端日志
|
||
重启后端服务后，查看控制台输出，应该看到类似这样的日志：
|
||
```
|
||
供应商查询结果 - ID: 61, 结果: {id=61, mobile=16666666666, username=测试供应商1}
|
||
供应商 - ID: 61, Username: 测试供应商1, Mobile: 16666666666
|
||
```
|
||
|
||
### 2. 检查API调用
|
||
确认前端调用的是正确的API：
|
||
- 前端调用：`/delivery/pageQueryList`
|
||
- 后端方法：`DeliveryController.pageQueryList` → `deliveryService.pageQuery`
|
||
|
||
### 3. 数据库验证
|
||
如果后端日志显示查询结果为空，可以执行以下SQL验证：
|
||
```sql
|
||
SELECT m.id, m.mobile, mu.username
|
||
FROM member m
|
||
LEFT JOIN member_user mu ON m.id = mu.member_id
|
||
WHERE m.id IN (61, 62, 63);
|
||
```
|
||
|
||
## 🎯 预期结果
|
||
|
||
### 如果 `member_user` 表中有用户名：
|
||
- `supplierName`: "测试供应商1"
|
||
- `buyerName`: "测试采购方1"
|
||
- `fundName`: "测试资金方1"
|
||
|
||
### 如果 `member_user` 表中用户名为空：
|
||
- `supplierName`: "16666666666" (回退到手机号)
|
||
- `buyerName`: "17777777777" (回退到手机号)
|
||
- `fundName`: "17777777771" (回退到手机号)
|
||
|
||
## 🔍 可能的问题原因
|
||
|
||
1. **后端服务没有重启**：修改没有生效
|
||
2. **数据库表结构**：`member_user` 表中可能没有对应的记录
|
||
3. **数据问题**：ID 61, 62, 63 在 `member_user` 表中可能不存在或 `username` 字段为空
|
||
4. **查询逻辑**：SQL查询可能有问题
|
||
|
||
## 📋 调试方法
|
||
|
||
### 1. 检查后端日志
|
||
查看是否有我们添加的调试日志输出
|
||
|
||
### 2. 检查数据库
|
||
```sql
|
||
-- 检查member表
|
||
SELECT * FROM member WHERE id IN (61, 62, 63);
|
||
|
||
-- 检查member_user表
|
||
SELECT * FROM member_user WHERE member_id IN (61, 62, 63);
|
||
|
||
-- 检查关联查询
|
||
SELECT m.id, m.mobile, mu.username
|
||
FROM member m
|
||
LEFT JOIN member_user mu ON m.id = mu.member_id
|
||
WHERE m.id IN (61, 62, 63);
|
||
```
|
||
|
||
### 3. 检查API响应
|
||
刷新前端页面，查看控制台"原始数据字段检查"日志
|
||
|
||
## ✅ 当前解决方案的优势
|
||
|
||
- **容错性强**：即使后端查询失败，也能显示手机号
|
||
- **用户体验好**：不会出现空白字段
|
||
- **调试友好**：有详细的日志输出
|
||
- **向后兼容**：不影响现有功能
|
||
|
||
## 🚀 下一步
|
||
|
||
1. 等待后端服务完全启动
|
||
2. 刷新前端页面
|
||
3. 查看后端日志输出
|
||
4. 检查API响应数据
|
||
5. 如果问题仍然存在，检查数据库表结构
|
||
|
||
现在请等待后端服务启动完成，然后测试功能并查看日志输出。
|