---
phase: affinity-P1
reviewed: 2026-05-13T00:00:00Z
depth: deep
files_reviewed: 6
files_reviewed_list:
  - qy_lty/userapp/models.py
  - qy_lty/device_interaction/models.py
  - qy_lty/userapp/migrations/0005_affinitysetting_affinitylevel_is_deleted_and_more.py
  - qy_lty/userapp/migrations/0006_migrate_favorability_to_userdevice.py
  - qy_lty/device_interaction/migrations/0003_userdevice_affinity_level_userdevice_favorability_and_more.py
  - qy_lty/userapp/management/commands/seed_affinity.py
findings:
  critical: 3
  warning: 9
  info: 6
  total: 18
status: issues_found
---

# 好感度系统 P1 数据层代码审查报告

**审查时间：** 2026-05-13
**审查深度：** deep（含 cross-app FK 与 cross-module 调用链分析）
**审查范围：** P1 阶段（P1-01 ~ P1-10）数据层产出物，共 6 个文件
**状态：** issues_found（3 critical / 9 warning / 6 info）

## Summary

P1 阶段建模整体方向是合理的：把好感度从 `ParadiseUser` 下沉到 `UserDevice` 是符合"一人多设备 / 设备级人格"业务语义的正确选择；规则 / 等级 / 日志 / 计数器 / 奖励发放记录五张表的拆分清晰；冗余 `rule_key` 字段、`event_id` 部分唯一索引、`reward_snapshot` JSON 快照等都是经验性的好实践。

但仍存在三类共 18 个需要在 P2 服务层动工之前修复的问题：

1. **完整性约束严重缺失**（Critical）：`AffinityRule` 没有任何 DB 级 CHECK 约束保证 `min_change <= max_change`、`cooldown_seconds >= 0`、`single_cap > 0`、`daily_cap > 0`；`AffinitySetting` 没保证 `decay_min_decay <= decay_max_decay <= decay_cap`；`AffinityLevel` 没保证 `min_affinity <= max_affinity` 且区间不重叠。一旦管理后台 / Admin / shell 写入异常值，P2 服务层的 `random.randint(min, max)` 会直接抛 `ValueError`，日上限会永远命中或永远不命中，是线上爆炸级风险。
2. **既有"换绑挤掉旧绑定"语义被 `is_active` 新字段悄悄破坏**（Critical）：现有 4 处 `UserDevice.objects.filter(device=...).order_by('-bound_at').first()` 调用点（`userapp/views.py:120`、`device_interaction/views.py:462/1158`、`serializers.py:125`）都没有过滤 `is_active=True`。一旦 P2 把解绑实现为软删（设 `is_active=False`），这些已经上线的代码会继续把旧的、已失效的绑定者当作"最新绑定者"返回，导致 MAC 登录拿到错误的 user-token、WS 分组路由到错误的 `device_{user_id}`。这是直接破坏运行中功能的语义回归。
3. **0006 数据迁移幂等性建立在脆弱的语义假设上**（Critical）：迁移用 `target.favorability == 10` 来判定"未迁移过"，但 10 既是初始值、也是衰减下限附近的常见值、也可能被管理员设为 10。重跑迁移会再次覆盖任何当前值正好为 10 的合法记录。回滚函数同样依赖 `!= 10` 判定，导致一旦正常运行了一段时间后再回滚，所有衰减回 10 的设备数据都不会被还原。

其它问题包括：`AffinitySetting.save()` 在并发下仍可能制造重复行、`UserAffinityDailyCounter` 与 `UserLevelRewardGrant` 的 `CASCADE` 与 `AffinityLog` 的 `SET_NULL` on_delete 行为不一致、`seed_affinity` 命令缺少 `companion_time` 类规则、整个 `handle` 包一个事务导致 force 模式的部分失败影响放大、`AffinityLevel` 区间没有 DB 唯一约束允许重叠区间、旧字段 `ParadiseUser.favorability` 没有标 deprecation 没有运行时拦截。

下文按严重性详列。修复优先级建议：**先解决 3 个 Critical（必须阻塞 P2）→ 再处理 9 个 Warning（建议在 P2 第一周完成）→ Info 可与 P2 服务层一起渐进改造**。

---

## Critical Issues

### CR-001：UserDevice 既有"最新绑定者"取数逻辑未过滤 is_active，导致软删后控制权解析错乱

**File:**
- `qy_lty/userapp/views.py:120`（MAC 登录）
- `qy_lty/device_interaction/views.py:462`（`bind_status`）
- `qy_lty/device_interaction/views.py:1158`（RTC token）
- `qy_lty/device_interaction/serializers.py:125`（绑定校验）
- 上述行为依赖 `qy_lty/device_interaction/models.py:122-126` 新增的 `is_active` 字段

**Issue:**
`UserDevice` 在 P1 引入了 `is_active` 字段（设计文档说"解绑置 false，重绑时可读取历史值"），但既有的 4 处"换绑挤掉旧绑定"调用点全部使用裸 `filter(device=device)` 后 `.order_by('-bound_at').first()` 形式，**没有过滤 `is_active=True`**：

```python
# userapp/views.py:120
user_device = UserDevice.objects.filter(device=device).order_by('-bound_at').first()

# device_interaction/views.py:462
user_device = UserDevice.objects.filter(device=device).first()  # 隐式依赖 Meta.ordering

# device_interaction/serializers.py:125
if value != 'AA:BB:CC:DD:EE:FF' and UserDevice.objects.filter(device=device).exists():
```

CLAUDE.md §"设备绑定与控制权"显式声明这是当前的**控制权解析规则**——同一台设备同一时刻只有最近一次绑定的那个用户能控制它。一旦 P2 把"解绑"实现为软删（设 `is_active=False`），这些已经上线的代码路径会继续把已失效的旧绑定者当作"最新绑定者"返回，造成：

- MAC 登录端点签发**已解绑用户**的 user-token（认证泄露）
- WebSocket 分组 `device_{user_id}` 路由到**已解绑用户**的频道（设备消息被前主人收到）
- RTC `room_id = room_{user_id}` 同上
- 重新绑定时 `UserDevice.objects.filter(device=device).exists()` 永远为 True，新用户永远绑不上

**Fix:**
在 P2 实现软删之前，先在所有 4 处调用点（以及未来新增的查询）显式加 `is_active=True` 过滤。建议增加一个 manager 强制：

```python
# qy_lty/device_interaction/models.py
class ActiveUserDeviceManager(models.Manager):
    def get_queryset(self):
        return super().get_queryset().filter(is_active=True)

class UserDevice(models.Model):
    # ...
    objects = models.Manager()           # 默认 manager，保留访问历史记录
    active = ActiveUserDeviceManager()   # 仅查询有效绑定
```

然后改写所有调用点为 `UserDevice.active.filter(device=device).order_by('-bound_at').first()`。同步更新 `qy_lty/CLAUDE.md` §"设备绑定与控制权"、`qy_lty/.planning/codebase/CONVENTIONS.md` 把"必须过滤 is_active"写成硬规则。

**影响范围：**
- 阻塞 P2 任何"解绑 = 软删"的设计
- 影响所有现存的 MAC 登录、WS 分组、RTC 房间路由
- 直接的安全 / 越权风险

---

### CR-002：AffinityRule / AffinityLevel / AffinitySetting 缺乏 DB 级 CHECK 约束，service 层会被脏数据击穿

**File:**
- `qy_lty/userapp/models.py:79-171`（`AffinityRule`）
- `qy_lty/userapp/models.py:174-244`（`AffinityLevel`）
- `qy_lty/userapp/models.py:247-314`（`AffinitySetting`）

**Issue:**
P2 服务层一定会做形如 `random.randint(rule.min_change, rule.max_change)`、`if today_total >= rule.daily_cap` 这样的运算。但当前模型对管理后台 / Admin / `python manage.py shell` / API 写入完全没有 DB 级保护：

1. `min_change > max_change` → `random.randint` 抛 `ValueError`，整个 apply 流程崩溃
2. `cooldown_seconds < 0` → 冷却计算 `last_trigger + timedelta(seconds=cooldown)` 得到过去时刻，永久解锁
3. `single_cap <= 0` → 任何变化值都被钳为 0
4. `daily_cap <= 0` → 第一次写入就触发上限
5. `AffinitySetting.decay_min_decay > decay_max_decay` → 衰减任务崩
6. `AffinitySetting.max_affinity < initial_affinity` → 新设备初始好感度已超上限
7. `AffinityLevel.min_affinity > max_affinity` → 该等级永远不触发
8. 多个 `AffinityLevel` 的区间可以**重叠**（如 Lv2 [21,40] 与 Lv3 [35,60]），服务端等级匹配结果取决于查询顺序，不确定
9. `AffinityLevel` 区间可以**留空隙**（如 Lv2 [21,40]、Lv3 [50,60]），好感度 45 的设备无等级

App 层校验（form / serializer / clean()）只是第一道防线，shell / 直 SQL / data migration / 第三方导入都能绕开。

**Fix:**
增加一个新迁移 `0007_add_affinity_check_constraints.py`，加 PostgreSQL CHECK 约束。Django 5 用 `models.CheckConstraint`：

```python
# AffinityRule.Meta
constraints = [
    models.CheckConstraint(
        check=Q(min_change__lte=F('max_change')),
        name='affinityrule_min_le_max',
    ),
    models.CheckConstraint(
        check=Q(cooldown_seconds__gte=0),
        name='affinityrule_cooldown_nonneg',
    ),
    models.CheckConstraint(
        check=Q(single_cap__gt=0),
        name='affinityrule_single_cap_positive',
    ),
    models.CheckConstraint(
        check=Q(daily_cap__gt=0),
        name='affinityrule_daily_cap_positive',
    ),
    # companion_time 类型时 min_continuous_minutes / max_count_per_day 必须非空
    models.CheckConstraint(
        check=(~Q(trigger_type='companion_time')) |
              (Q(min_continuous_minutes__gt=0) & Q(max_count_per_day__gt=0)),
        name='affinityrule_companion_fields_present',
    ),
]

# AffinityLevel.Meta
constraints = [
    models.CheckConstraint(
        check=Q(min_affinity__lte=F('max_affinity')),
        name='affinitylevel_min_le_max',
    ),
    models.CheckConstraint(
        check=Q(reward_currency__gte=0),
        name='affinitylevel_currency_nonneg',
    ),
]

# AffinitySetting.Meta
constraints = [
    models.CheckConstraint(
        check=Q(decay_min_decay__lte=F('decay_max_decay')),
        name='affinitysetting_decay_min_le_max',
    ),
    models.CheckConstraint(
        check=Q(decay_max_decay__lte=F('decay_cap')),
        name='affinitysetting_decay_within_cap',
    ),
    models.CheckConstraint(
        check=Q(initial_affinity__lte=F('max_affinity')),
        name='affinitysetting_initial_le_max',
    ),
    models.CheckConstraint(
        check=Q(decay_min_floor__lte=F('max_affinity')),
        name='affinitysetting_floor_le_max',
    ),
]
```

同时在模型 `clean()` 加 Python 级校验，并在管理后台 / DRF serializer 显式 `full_clean()`，给前端友好错误信息。

**等级区间不重叠 / 不留空隙**用 DB 约束实现成本极高（需要 exclusion constraint + btree_gist），建议保留在应用层：在 `AffinityLevel.clean()` 检查 `min_affinity` 等于上一级 `max_affinity + 1`，并在 `seed_affinity` 验证完整覆盖 `[0, max_affinity]`。

**影响范围：**
- 阻塞 P2 服务层（否则随时会因为脏配置崩溃）
- 数据完整性、运维侧的可观测性
- 管理后台需要补充对应的前端表单校验

---

### CR-003：0006 数据迁移用 `target.favorability == 10` 做幂等条件，存在数据覆盖与回滚失效双重风险

**File:** `qy_lty/userapp/migrations/0006_migrate_favorability_to_userdevice.py:54-58, 67-85`

**Issue:**
forward 函数的幂等条件：

```python
if target.favorability == 10:        # 行 55
    target.favorability = favorability
    target.save(update_fields=['favorability'])
    migrated_count += 1
```

backward 函数的回滚条件：

```python
if primary and primary.favorability != 10:   # 行 80
    user.favorability = primary.favorability
    user.save(update_fields=['favorability'])
```

10 是 `UserDevice.favorability` 字段的 model 默认值，也是 `AffinitySetting.initial_affinity` 的默认值，意味着：

1. **未来某用户合法地把好感度衰减到 10**（衰减任务跑了一段时间后），如果运维误执行 `migrate --fake` 后再 `unfake` 或重做某次回滚 / 重跑，forward 会**再次把 ParadiseUser.favorability 旧值（很可能是迁移时的快照）写回**，覆盖正常衰减后的当前值，造成业务数据错乱
2. **管理员手工把好感度调整为 10**，下一次重跑迁移同样会被覆盖
3. **backward 在系统稳定运行一段时间后执行**，由于 forward 早已完成，所有非 10 的设备会被回写到 `ParadiseUser.favorability`——但 `ParadiseUser.favorability` 此时是过期数据（业务代码已经全部走 `UserDevice`），回写没有意义；同时所有当前正好为 10 的设备会**被跳过回写**，导致迁移前那批好感度 = 10 的用户**永久丢失**原 favorability 值（如果他们在 forward 时本来有非零 ParadiseUser.favorability 但被跳过）
4. 用户提到迁移已经在 makemigrations 后第二次启动时跑过一次，输出"9 个零值跳过 + 1 个无设备跳过 + 0 成功"——这意味着实际成功迁移条数为 0，但 `MigrationRecorder` 已记录迁移完成。如果以后再有用户从老库恢复数据（FK fixture / dumpdata），无法再次自动迁移

**Fix:**
方案 A（推荐，引入幂等标记）：用 `AffinityLog` 或 metadata 标记已迁移：

```python
def migrate_favorability_forward(apps, schema_editor):
    ParadiseUser = apps.get_model('userapp', 'ParadiseUser')
    UserDevice = apps.get_model('device_interaction', 'UserDevice')
    AffinityLog = apps.get_model('userapp', 'AffinityLog')

    for user in ParadiseUser.objects.iterator():
        favorability = getattr(user, 'favorability', 0) or 0
        if favorability <= 0:
            continue
        target = (
            UserDevice.objects.filter(user_id=user.id, is_primary=True)
                .order_by('-bound_at').first()
            or UserDevice.objects.filter(user_id=user.id)
                .order_by('-bound_at').first()
        )
        if target is None:
            continue
        # 用 AffinityLog 中是否存在 source='data_migration' 的记录做幂等
        already = AffinityLog.objects.filter(
            device_id=target.id, source='data_migration'
        ).exists()
        if already:
            continue
        before = target.favorability
        target.favorability = favorability
        target.save(update_fields=['favorability'])
        AffinityLog.objects.create(
            user_id=user.id, device_id=target.id,
            rule_key='', change_value=favorability - before,
            before_value=before, after_value=favorability,
            source='data_migration',
            metadata={'migration': '0006', 'from_user_favorability': favorability},
        )
```

注意要先把 `'data_migration'` 加入 `AffinityLog.SOURCE_CHOICES`。

方案 B（最小改动）：用 `UserDevice` 新增临时字段 `_migrated_from_user_favorability`（bool default False），forward 写入时设为 True，幂等判断改为 `if not target._migrated_from_user_favorability`。完成后用单独迁移删字段。

方案 C（最低成本）：直接接受迁移**不可重跑**，把 forward 改为**判断 `MigrationRecorder` 状态**：若 `0006` 已经在 `django_migrations` 表中存在则 noop。这是 Django 迁移系统的默认语义，但需要在 `RunPython` 内显式检查，避免人为 `--fake` 后再 `unfake` 触发。

backward 同样需要重写：不应依赖 `!= 10`，而应使用 forward 写入的 metadata 反向查询。

**影响范围：**
- 重跑迁移会覆盖正常业务数据
- 回滚语义不可靠
- P3 / P4 衰减跑起来后这个迁移会变成"定时炸弹"

---

## Warnings

### WR-001：AffinitySetting.save() 单例保证在并发下仍可能制造重复行

**File:** `qy_lty/userapp/models.py:303-308`

**Issue:**

```python
def save(self, *args, **kwargs):
    if not self.pk and AffinitySetting.objects.exists():
        existing = AffinitySetting.objects.first()
        self.pk = existing.pk
    super().save(*args, **kwargs)
```

在多 worker（gunicorn / daphne 多进程）或并发 admin 操作下，两个进程的 `AffinitySetting.objects.exists()` 调用可以同时返回 `False`（首次部署 / 表为空时），随后两个 `INSERT` 都成功，得到两条记录。即便表不为空，`AffinitySetting.objects.first()` 读到的两个 pk 可能不同（理论上单例表不存在这种情况，但代码不应假设），随后两个 `UPDATE` 都成功——总体上单例保证是 best-effort 的，不是强约束。

**Fix:**
1. 把 `get_solo()` 改为 `pk=1` 硬编码 + `update_or_create`：

```python
@classmethod
def get_solo(cls):
    instance, _ = cls.objects.get_or_create(pk=1, defaults={})
    return instance

def save(self, *args, **kwargs):
    # 强制 pk=1 单例
    if not self.pk:
        self.pk = 1
    super().save(*args, **kwargs)
```

2. 同时加 DB 级 CHECK 约束防御：

```python
constraints = [
    models.CheckConstraint(check=Q(pk=1), name='affinitysetting_singleton'),
]
```

虽然 CHECK 约束在 PostgreSQL 下不能跨行验证（不能强制"全表只有 1 行"），但 `pk=1` 约束可以阻止任何非 1 的主键，配合应用层 `force pk=1` 就能形成事实单例。

**影响范围：**
- 影响低（首次部署窗口期），但配置型数据出现重复行后续排查极痛苦

---

### WR-002：UserAffinityDailyCounter / UserLevelRewardGrant on_delete 与 AffinityLog 不一致

**File:**
- `qy_lty/userapp/models.py:339`（AffinityLog.device → SET_NULL）
- `qy_lty/userapp/models.py:415`（UserAffinityDailyCounter.device → CASCADE）
- `qy_lty/userapp/models.py:453`（UserLevelRewardGrant.device → CASCADE）

**Issue:**
设计意图明确是"AffinityLog 历史保留"（已注释"rule 用 SET_NULL，规则被删除后日志保留"），但 `UserDevice` 一旦被硬删，`UserLevelRewardGrant` 会跟着级联删除——这破坏了**奖励发放的永久幂等性**：如果未来某天用户重新绑定该设备（虽然现在的设计是 UserDevice 软删，但 Device 本身仍可能被运营删除），原来的发放记录会消失，重新发奖会再次成立。

`UserAffinityDailyCounter` CASCADE 是合理的（计数器本就是每日重置 + Redis 兜底），但 `UserLevelRewardGrant` 应该和 `AffinityLog` 保持一致 → `SET_NULL`（device 可空）或 `PROTECT`。

**Fix:**

```python
# UserLevelRewardGrant
device = models.ForeignKey(
    'device_interaction.UserDevice', on_delete=models.SET_NULL,
    verbose_name='用户设备绑定', related_name='level_reward_grants',
    null=True, blank=True,
)
```

同时把 `unique_together = [('device', 'level')]` 改为只在 device 非空时唯一（用 `UniqueConstraint(condition=Q(device__isnull=False))`），并冗余一份 `device_snapshot_id`（IntegerField, null=True）保存被删 device 的原 pk 以便审计。

如果产品 / 运营明确说"Device 删除 = 奖励历史就该清空"，那要把这个决策写到设计文档里，并在两处保持一致：`AffinityLog.device` 也要改成 CASCADE。当前两边不一致明显是没对齐设计意图。

**影响范围：**
- 数据保留语义不一致
- 审计 / 合规风险

---

### WR-003：AffinityLog 索引设计偏重，写入开销可能放大 5 倍

**File:** `qy_lty/userapp/models.py:387-399`

**Issue:**
当前定义了 6 个索引：

- `created_at` (db_index=True，单字段)
- `event_id` (db_index=True，单字段)
- `(device, -created_at)` 复合
- `(user, -created_at)` 复合
- `(rule_key, -created_at)` 复合
- `(source, -created_at)` 复合
- `unique_affinity_event_id` partial unique

P2 后端服务每次 apply 都会写 1 条 AffinityLog，热点写场景下每行写入需要更新 7 个 B-tree 节点（含主键），写放大显著。

实际查询模式（参考设计文档 §7 客户端接口、§9 管理后台）只用到：

- **客户端拉取最近变化**：`(device, -created_at)` 命中
- **管理后台日志列表**：可能按 user / source / rule_key 过滤
- **幂等去重**：`event_id` 命中

`(user, -created_at)` 实质冗余——用户视角的查询可以走 `device` 表 join 实现（且数据量比 device 维度大）；`(source, -created_at)` 主要用于管理后台筛选，可以用 `created_at` 单字段索引 + source 过滤实现，PG 在低基数列上即便走 seq scan + index 也不会太慢。

**Fix:**
P1 阶段建议先保留 `(device, -created_at)`、`event_id` partial unique、`created_at` 单字段；删除 `(user, -created_at)`、`(rule_key, -created_at)`、`(source, -created_at)`。等 P5 上线、有真实查询 profile 后再按需加索引。如果坚持保留管理后台过滤，建议改为 PostgreSQL BRIN 索引（对 `created_at` 等只增字段非常高效）：

```python
from django.contrib.postgres.indexes import BrinIndex
indexes = [
    models.Index(fields=['device', '-created_at']),
    BrinIndex(fields=['created_at']),
]
```

**影响范围：**
- 写入吞吐
- 表空间占用

---

### WR-004：unique_affinity_event_id 部分唯一索引语义有歧义，空字符串作为"无 event_id"标记不安全

**File:** `qy_lty/userapp/models.py:393-399`

**Issue:**

```python
constraints = [
    UniqueConstraint(
        fields=['event_id'],
        condition=Q(event_id__gt=''),
        name='unique_affinity_event_id',
    ),
]
```

PostgreSQL 下这会生成 `CREATE UNIQUE INDEX ... WHERE event_id > ''`，是合法的 partial index。但有两个问题：

1. **`event_id__gt=''` 语义脆弱**：依赖 `event_id` 是字符串、依赖 `''` 是 "无值"标记。如果未来某客户端 bug 传了 `' '`（空格）或 `'null'`，会被当作有效 event_id 进入唯一约束。
2. **CharField 默认值缺失**：`event_id = models.CharField(..., blank=True, db_index=True)`，没有显式 `default=''`。Django 在 IntegerField/CharField 上 blank=True 不等同于 default=''，admin 直接保存可能存为 `None`（虽然 CharField 默认 null=False，但 raw SQL / fixtures 可能注入 NULL）。`event_id__gt=''` 对 NULL 不命中，约束失效。

更标准的做法是用 `null=True, blank=True` 配合 `condition=Q(event_id__isnull=False)`：

**Fix:**

```python
event_id = models.CharField(
    '事件ID', max_length=64, null=True, blank=True, db_index=True,
    help_text='客户端事件 UUID，用于幂等去重；NULL 表示非客户端来源（衰减/管理员调整）',
)

class Meta:
    constraints = [
        UniqueConstraint(
            fields=['event_id'],
            condition=Q(event_id__isnull=False),
            name='unique_affinity_event_id',
        ),
    ]
```

PostgreSQL 下 NULL 不参与 unique 索引，正好就是想要的语义；且 NULL 比 `''` 更明确地表达"无值"。

同步在 P2 服务层加输入校验：长度 < 16 或不符合 UUID 格式的 event_id 一律拒绝并报错。

**影响范围：**
- 幂等去重的健壮性
- 兼容性（migration 需要 `RunPython` 把现有 `event_id=''` 改成 NULL）

---

### WR-005：seed_affinity 缺少 trigger_type='companion_time' 类规则，但模型已支持

**File:** `qy_lty/userapp/management/commands/seed_affinity.py:28-77`

**Issue:**
`AffinityRule` 模型在 P1-02 增加了 `trigger_type='companion_time'` 选项与 `min_continuous_minutes` / `max_count_per_day` 配套字段，设计文档 §4.2 表格中应有"陪伴时长"规则（每 30 分钟 +1，每日最多 4 次之类），但 `DEFAULT_RULES` 8 条中 7 条是 `action`、1 条是 `decay`，**0 条 companion_time**。

后续 P3 服务层如果按"规则配置驱动"实现陪伴时长检测，运行时会**找不到任何 companion_time 规则**，要么静默忽略要么报错。

**Fix:**

```python
# DEFAULT_RULES 追加
{
    'rule_key': 'companion_30min', 'name': '陪伴 30 分钟',
    'description': '与洛天依持续陪伴 30 分钟可获得好感度',
    'trigger_type': 'companion_time',
    'min_change': 1, 'max_change': 2, 'single_cap': 2, 'daily_cap': 8,
    'cooldown_seconds': 0, 'is_negative': False, 'is_enabled': True,
    'min_continuous_minutes': 30, 'max_count_per_day': 4,
},
```

具体数值需要和产品 / 设计文档对齐；如果设计文档暂未明确，应在 seed 中加注释说明"待定，参见 §4.2"。

另外建议把 DEFAULT_RULES 抽到 `qy_lty/userapp/affinity/defaults.py`，避免 management command 文件膨胀，且方便单元测试引用。

**影响范围：**
- P3 陪伴时长功能阻塞
- 测试覆盖率

---

### WR-006：AffinityLevel.description 在 seed 中未设置，依赖 model `blank=True` 隐式 ''；未来字段改为 required 会一次性报错

**File:**
- `qy_lty/userapp/management/commands/seed_affinity.py:81-112`
- `qy_lty/userapp/models.py:196` (`description = models.TextField('等级描述', blank=True)`)

**Issue:**
当前 `AffinityLevel.description` 在 model 是 `blank=True` 但**没有 default**，Django 在 `create(**spec)` 时如果 spec 没有 `description` 键，会在 Python 层报错（除非 PostgreSQL 那侧字段允许 NULL，但 TextField 默认 NOT NULL）。

实测时为什么没崩？因为 Django 5 对 TextField + `blank=True` 在 Python 层会注入 `''` 作为隐式默认值。但这是 Django 内部行为，不是合约。一旦未来把 description 改成 required（`blank=False`）或加 unique，seed 会一次性失败。

**Fix:**
显式补齐：

```python
DEFAULT_LEVELS = [
    {
        'level': 1, 'name': '初识',
        'description': '初次相识阶段，了解彼此的基础阶段',  # 显式
        # ...
    },
    ...
]
```

模型侧也建议补 `default=''`：

```python
description = models.TextField('等级描述', blank=True, default='')
```

`AffinityRule.description` 同样问题。

**影响范围：**
- 健壮性
- 未来 schema 演进

---

### WR-007：seed_affinity @transaction.atomic 包整个 handle，force 模式下部分失败会回滚所有已处理项

**File:** `qy_lty/userapp/management/commands/seed_affinity.py:124-136`

**Issue:**

```python
@transaction.atomic
def handle(self, *args, **options):
    force = options['force']
    self._seed_setting()
    rules_created, rules_updated = self._seed_rules(force)
    levels_created, levels_updated = self._seed_levels(force)
    self.stdout.write(self.style.SUCCESS(f'\n[seed_affinity] 完成：...'))
```

如果 force 模式下处理第 6 条 rule 时崩溃（例如 JSON 字段格式错），前 5 条 rule 的 update 全部回滚，但 stdout 已经打印 `~ 规则 xxx 已覆盖` 5 次，造成"显示成功但实际未生效"的语义错位，运维排查时会被误导。

**Fix:**
两种方案：

方案 A（推荐，每条独立事务）：

```python
def _seed_rules(self, force):
    created, updated = 0, 0
    for spec in DEFAULT_RULES:
        try:
            with transaction.atomic():
                # ... 单条处理
        except Exception as e:
            self.stderr.write(self.style.ERROR(f'  ! 规则 {spec["rule_key"]} 处理失败: {e}'))
            continue
    return created, updated
```

并去掉 `handle` 上的 `@transaction.atomic`。这样部分失败不影响其他规则。

方案 B（保留全局事务，但把 stdout 改为推迟输出）：

```python
def handle(self, *args, **options):
    force = options['force']
    messages = []
    try:
        with transaction.atomic():
            self._seed_setting(messages)
            self._seed_rules(force, messages)
            self._seed_levels(force, messages)
    except Exception:
        self.stderr.write(self.style.ERROR('[seed_affinity] 事务回滚，未做任何修改'))
        raise
    for m in messages:
        self.stdout.write(m)
```

方案 A 更符合 seed 命令的运维场景（部分失败可重跑），方案 B 更符合"全有全无"的事务语义。建议方案 A。

**影响范围：**
- 运维诊断
- 数据一致性误判

---

### WR-008：ParadiseUser.favorability 旧字段保留但无运行时拦截，存在双轨数据写入风险

**File:** `qy_lty/userapp/models.py:29`

**Issue:**

```python
favorability = models.IntegerField('好感度', default=0)
```

数据迁移 0006 把数据搬到 `UserDevice.favorability` 后，`ParadiseUser.favorability` 仍然是普通字段，可读可写。但代码库内仍有引用风险：

- `userapp/serializers.py` 可能仍序列化此字段（未审查到具体文件，需 grep）
- 管理后台 `userapp/admin.py` 可能仍在编辑界面暴露
- 老的 API 客户端可能仍在 PATCH 这个字段
- 团队成员可能在 P2 写新代码时仍然 `user.favorability += 1`

一旦双写存在，数据双轨：`ParadiseUser.favorability` vs `UserDevice.favorability` 不一致，后续审计极痛苦。

**Fix:**
分两步：

第一步（P1 收尾，立即做）：把字段标 deprecated，在 model 层 override `__setattr__` 或 property 拦截写：

```python
# userapp/models.py
@property
def favorability(self):
    import warnings
    warnings.warn(
        'ParadiseUser.favorability 已弃用，请使用 UserDevice.favorability。'
        '此 property 仅返回主设备值，不应用于业务逻辑。',
        DeprecationWarning, stacklevel=2,
    )
    primary = self.devices.filter(is_primary=True, is_active=True).first()
    return primary.favorability if primary else 0

@favorability.setter
def favorability(self, value):
    raise AttributeError(
        'ParadiseUser.favorability 已弃用，写操作不允许。请操作 UserDevice.favorability。'
    )
```

但 property 不能直接覆盖 model field——需要重命名 DB 字段为 `_legacy_favorability` 然后加一个迁移：

```python
# 0007_deprecate_user_favorability.py
operations = [
    migrations.RenameField(
        model_name='paradiseuser',
        old_name='favorability',
        new_name='_legacy_favorability',
    ),
]
```

第二步（下个版本）：彻底 `migrations.RemoveField`。同时审计所有 `serializers.py` / `admin.py` / `views.py` 中对 `paradiseuser.favorability` 的引用。

**影响范围：**
- 数据一致性
- 跨模块代码引用清理

**注意：** 由于该 property 形式会触发 N+1（每次访问都查 devices），P2 后端的 serializer 应该改为直接展示 UserDevice 列表而不是 ParadiseUser.favorability。在做 property 改造前，先全文搜索 `favorability` 字段被哪里读写：

```
grep -rn 'favorability' qy_lty/ --include='*.py'
```

并清单化每个调用点的修复计划。

---

### WR-009：AffinityLevel 区间允许重叠 / 留空隙，等级匹配结果不确定

**File:** `qy_lty/userapp/models.py:174-244`

**Issue:**
设计文档 §6.2 假定等级区间是 `[0,20], [21,40], [41,60], [61,80], [81,100]` 完整覆盖且不重叠。但 model 没有任何约束防止：

- 重叠：Lv2 `min_affinity=21, max_affinity=40`、Lv3 `min_affinity=35, max_affinity=60` → 好感度 38 同时匹配 Lv2 和 Lv3，服务端取等级取决于查询排序
- 空隙：Lv2 `[21,40]`、Lv3 `[50,60]` → 好感度 45 的设备等级查不出来，缓存 `affinity_level` 字段无值

P2 / P3 服务层等级计算 `AffinityLevel.objects.filter(min_affinity__lte=v, max_affinity__gte=v).first()` 会静默取一个，不报错。

**Fix:**
PostgreSQL 用 `EXCLUDE` constraint + `btree_gist` 扩展可以保证区间不重叠：

```python
# AffinityLevel.Meta
constraints = [
    ExclusionConstraint(
        name='affinitylevel_no_overlap',
        expressions=[
            (NumRange('min_affinity', 'max_affinity', '[]'), '&&'),
        ],
    ),
]
```

但需要在迁移里 `CREATE EXTENSION btree_gist`，部署成本上升。

更简单的方案：在 `AffinityLevel.clean()` 加 Python 校验，加 `seed_affinity` / management command `verify_affinity_levels` 检查完整覆盖：

```python
def clean(self):
    super().clean()
    if self.min_affinity > self.max_affinity:
        raise ValidationError({'max_affinity': '上限不能小于下限'})
    # 与其他等级的重叠检查
    overlaps = AffinityLevel.objects.exclude(pk=self.pk).filter(
        Q(min_affinity__lte=self.max_affinity) &
        Q(max_affinity__gte=self.min_affinity) &
        Q(is_deleted=False)
    )
    if overlaps.exists():
        raise ValidationError(
            f'与等级 {", ".join(str(l) for l in overlaps)} 区间重叠'
        )
```

并在 admin / serializer 显式 `full_clean()`。

**影响范围：**
- 等级计算的正确性
- 缓存 `UserDevice.affinity_level` 字段的可信度

---

## Info

### IN-001：AffinityRule 旧字段 points / daily_limit / is_active 缺乏 db_column 与显式 deprecation 路径

**File:** `qy_lty/userapp/models.py:148-160`

**Issue:**
注释说"下个版本删除"，但没有：
- TODO / FIXME 关联 ticket / version
- `RemovedInVNextWarning` 装饰
- 哪个版本会删的具体说明

后续开发者（包括 LLM agent）查这些字段时只能靠 docstring。

**Fix:**
加显式注释：

```python
points = models.IntegerField(
    '积分(已弃用)', default=0,
    help_text='[DEPRECATED v0.3 → v0.4 删除] 使用 min_change/max_change',
)
```

或者用 Python 级 warnings，在 model property 上拦截访问。同时在 `docs/好感度系统-开发任务清单.md` 加一条"P1-收尾：清理 deprecated 字段"。

---

### IN-002：DEFAULT_RULES 和 DEFAULT_LEVELS 应抽到独立模块便于复用

**File:** `qy_lty/userapp/management/commands/seed_affinity.py:28-112`

**Issue:**
两个常量 dict 占了 80% 文件，且 P2 单元测试 / 集成测试也会需要这些 fixture（"给我一个默认 chat 规则"）。当前埋在 management command 文件里只能通过 `from userapp.management.commands.seed_affinity import DEFAULT_RULES` 导入，路径丑陋且非常规。

**Fix:**

```python
# qy_lty/userapp/affinity/defaults.py
DEFAULT_RULES = [...]
DEFAULT_LEVELS = [...]
DEFAULT_SETTING = {...}

# seed_affinity.py
from userapp.affinity.defaults import DEFAULT_RULES, DEFAULT_LEVELS
```

测试代码、P2 service 层、文档生成都可以复用。

---

### IN-003：AffinityRule.daily_cap 与 AffinitySetting.daily_cap 同名易混淆

**File:**
- `qy_lty/userapp/models.py:124` (`AffinityRule.daily_cap`)
- `qy_lty/userapp/models.py:263` (`AffinitySetting.daily_cap`)

**Issue:**
P2 / P3 服务层代码会同时引用两者，`if today_total >= rule.daily_cap` 和 `if global_today_total >= setting.daily_cap` 容易拼错。

**Fix:**
建议把 `AffinitySetting.daily_cap` 重命名为 `global_daily_cap` 或 `daily_cap_global`，让一眼区分。需要一个 `RenameField` 迁移，成本不高。

---

### IN-004：AffinityLog __str__ 在 self.id 为 None（未保存）时会显示 #None

**File:** `qy_lty/userapp/models.py:401-402`

**Issue:**

```python
def __str__(self):
    return f"#{self.id} {self.rule_key or self.source} {self.before_value}->{self.after_value}"
```

`AffinityLog(...)` 但未 save 时 `self.id` 是 None，调试输出形如 `#None chat 0->5`。无功能影响，但不优雅。

**Fix:**

```python
def __str__(self):
    return f"#{self.pk or 'new'} {self.rule_key or self.source} {self.before_value}->{self.after_value}"
```

---

### IN-005：UserDevice.is_active 与 Device.is_active 命名冲突，help_text 已警告但仍建议改名

**File:** `qy_lty/device_interaction/models.py:122-126`

**Issue:**
`Device.is_active`（行 50）表示"设备已激活"，`UserDevice.is_active`（新增）表示"绑定关系有效"。help_text 已经显式说"与 Device.is_active 不是同一概念"——这本身就是一个 code smell 信号。

后续 `select_related('device')` 时 `ud.device.is_active` vs `ud.is_active` 表达截然不同的语义，极易拼错。

**Fix:**
建议把 `UserDevice.is_active` 重命名为 `is_binding_active` 或 `is_bound`：

```python
is_bound = models.BooleanField(
    '绑定有效', default=True,
    help_text='软删除标记。解绑置为 false，重绑时可读取历史值。',
)
```

需要新迁移 `RenameField`，但 P1 尚未上线（按用户描述"纯数据层工作"），改名成本低。如果已有数据写入，必须按 CR-001 同步修改所有调用点。

---

### IN-006：0006 数据迁移 print 输出无前缀格式，迁移日志难以 grep

**File:** `qy_lty/userapp/migrations/0006_migrate_favorability_to_userdevice.py:60-64, 85`

**Issue:**

```python
print(
    f"\n[P1-09] favorability 数据迁移完成："
    f"成功 {migrated_count}，无设备跳过 {skipped_no_device}，"
    f"零值跳过 {skipped_zero}"
)
```

Django 推荐迁移内用 `schema_editor.connection.ops.executor.stdout` 或 `apps.get_app_config('userapp').stdout`，更标准的是 `print` 但加上 `[migration 0006_xxx]` 前缀。当前以 `[P1-09]` 业务标识写死，未来根据迁移文件名查找时不方便。

**Fix:**

```python
print(f"\n[migration 0006_migrate_favorability] forward: 成功={migrated_count}, "
      f"无设备={skipped_no_device}, 零值={skipped_zero}")
```

并把所有迁移内 print 改用统一格式。

---

## 修复优先级建议

| 优先级 | 编号 | 阻塞 | 建议时机 |
|--------|------|------|----------|
| P0 | CR-001 | P2 软删 / 已存在功能回归 | **必须**在 P2 service 层落地前修复，最迟本周 |
| P0 | CR-002 | P2 service 层稳定性 | **必须**在 P2 service 层落地前修复 |
| P0 | CR-003 | 重跑迁移 / 数据完整性 | 立即修复（已有迁移）+ 写运维 SOP "不可重跑此迁移" |
| P1 | WR-001 ~ WR-009 | 部分阻塞 P2/P3 | P2 第一周完成 |
| P2 | IN-001 ~ IN-006 | 不阻塞 | 与 P2/P3 渐进改造 |

特别注意 CR-001 与 IN-005 是配对的——改名 + 加 manager + 修所有调用点 + 更新 CLAUDE.md，应作为同一个 commit 完成，避免半成品状态。

---

## Cross-Module 调用链分析（deep 模式补充）

按用户在配置中明确要求做 cross-app FK 与 cross-module 调用链审查，补充如下：

### Call Chain 1：MAC 登录 → UserDevice 控制权解析

```
MAC 设备 →
  userapp/views.py:120 UserDevice.objects.filter(device=device).order_by('-bound_at').first() →
  签发 user-token →
  device_interaction/auth.py 解析 token →
  WS connect → group = device_{user_id}
```

**风险：** 全程未过滤 `is_active`。详见 CR-001。

### Call Chain 2：好感度变更 → 日志 → 等级 → 奖励发放（未来 P2/P3）

```
事件接收 →
  AffinityRule 查询（按 rule_key） →
  random.randint(min_change, max_change) →
  UserAffinityDailyCounter 累加 + AffinitySetting.daily_cap 检查 →
  UserDevice.favorability 写 →
  AffinityLog 写（event_id 幂等）→
  AffinityLevel 区间匹配 →
  UserLevelRewardGrant 写（unique 防重复）→
  WebSocket 推送
```

**潜在风险点：**
- AffinityRule.min_change > max_change → `random.randint` 崩（CR-002）
- AffinityRule 不存在 `companion_time` 规则 → 陪伴时长事件被忽略（WR-005）
- AffinityLevel 区间重叠 → 等级匹配结果不确定（WR-009）
- UserLevelRewardGrant.device CASCADE → 设备删后奖励历史丢失（WR-002）
- AffinityLog.event_id 用 `''` 而非 NULL → 幂等失效边界 case（WR-004）

### Cross-App FK 一致性检查

| FK | on_delete | 设计意图 | 实际表现 | 一致？ |
|----|-----------|---------|---------|--------|
| AffinityLog.device | SET_NULL | 历史保留 | ✓ | ✓ |
| AffinityLog.rule | SET_NULL | 规则删后日志保留 | ✓ + rule_key 冗余 | ✓ |
| AffinityLog.user | CASCADE | 用户注销清理 | ✓ | ✓ |
| UserAffinityDailyCounter.device | CASCADE | 计数器随设备删 | ✓ | ✓（合理） |
| UserAffinityDailyCounter.rule | CASCADE | 规则删后计数器删 | ⚠ 与 AffinityLog.rule SET_NULL 不一致 | 部分一致 |
| UserLevelRewardGrant.device | CASCADE | ? | 设计意图未明确，造成歧义 | ✗ (WR-002) |

`UserAffinityDailyCounter.rule` 用 CASCADE 也值得讨论：一条 rule 被软删后（`is_deleted=True`），新事件不会再用，但旧的当天计数器仍在使用中。建议保持 CASCADE 但补充设计文档说明"软删 rule 时业务必须等当天计数器清零再硬删"。

---

_Reviewed: 2026-05-13T00:00:00Z_
_Reviewer: Claude (gsd-code-reviewer)_
_Depth: deep_
_Note: 本次审查不在 GSD .planning/phase-N 结构内，按用户要求保存到 docs/REVIEW-affinity-P1.md_