3.1 KiB
is_mark_read=1 实测影响范围
授权与操作
用户确认当前有未读通知，并明确要求发送请求后检查是否变为已读。本次仅执行一次带标记的列表请求，不点击通知面板，不发送点赞、关注、评论等操作。
登录态检查成功，账号为「抖咅求真」。先用 is_mark_read=0、count=10 保存基线；再用同一列表接口 is_mark_read=1、count=1；最后用 is_mark_read=0、count=10 重读，对比通知 ID 的 has_read。
接口：GET /aweme/v1/web/notice/，其他参数为 device_platform=webapp、aid=6383、channel=channel_pc_web、is_new_notice=1、notice_group=960、min_time=0、max_time=0。
实测结果
| 通知 ID | 请求前 | 标记请求是否返回 | 重新查询后 |
|---|---|---|---|
| 7682073499761968177 | has_read=false | 是 | has_read=true |
| 7682073400638342193 | has_read=false | 否 | has_read=true |
- 标记请求 HTTP 200，status_code=0，只返回 1 条。
- 原先 2 条未读均变成已读，包括未返回的第二条。
- 其余已读记录仍为已读。
- 这次实际修改了远端未读状态，未尝试恢复。
结论：网页列表请求确实能触发已读，但影响范围超出本次返回的通知，不能用 count 限制为“只标记本次获取的数据”。
本次样本只证明返回范围外也被标记；未证明整个分组的所有历史通知必然都受影响，也未排除时间水位等服务端实现。没有用大量未读数据测试跨页边界，没有把单次实验泛化成精确的全局规则。
因此保持正式脚本 --mark-readed 的安全阻断：当前用户约束仍是只影响本次数据，本次实验授权不等于永久接受分组批量标记。
证据与复用
src/notice_mark_before.json：首次只读观察。src/notice_mark_verification.json：正式实验基线、标记响应、重读响应、逐条对比和时间。src/verify_notification_mark_read.py：独立实验入口，复用同目录的现有登录检查和只读通知请求。src/test_verify_notification_mark_read.py：离线检查实验流程。
# 默认只读取与保存基线，绝不标记
python3 src/verify_notification_mark_read.py
# 明确授权后才使用；可能标记返回范围外的消息
python3 src/verify_notification_mark_read.py --apply
# 离线，不修改远端
python3 src/test_verify_notification_mark_read.py
安装依赖不变：Python、browser-harness、允许本机 CDP 的 Chrome 和手动登录账号。详见 2026-09-05-23-15-current-user-notifications.md；没有新依赖，不硬编码账号或凭证。
实验脚本先保存基线再发标记；没有未读时不发标记，登录校验失败则退出；不自动重试有副作用的请求。超时不代表服务端未生效，应先读取保存证据并重新查询，不直接重试 --apply。
离线检查通过，覆盖默认不标记、显式 --apply 才发一次请求、count=1 参数以及范围外状态变化对比。真实实验也成功。Pyright 对新增同目录模块出现无法解析的缓存诊断，实际 Python 导入执行通过，已记录为误报。