行为数据应先缓冲（Redis队列或Kafka）、再聚合、后打标；标签需配置化规则引擎实现窗口聚合；画像须分层存储于user_tags和user_segments表，避免字符串拼接。
行为数据怎么收：别直接往 MySQL 里狂插
用户点击、页面停留、滚动深度这些行为，高频且量大，如果每个动作都 INSERT INTO behavior_log 一次，数据库很快会成为瓶颈，尤其在秒级并发 >100 的场景下。真正可行的路径是「先缓冲、再聚合、后打标」。
推荐用 Redis 的 LPUSH + BRPOP 搭配队列消费（如 PHP CLI 脚本或 Supervisor 管理的常驻进程），把原始行为压进列表；或者更稳一点，走 Kafka / RabbitMQ 中转。PHP 层只做轻量埋点上报，例如：
// 前端触发，后端接收
file_get_contents("http://log-api/?uid=123&event=click&page=home&ts=" . time());
// 或用 cURL 异步发，不阻塞主流程
- 避免在
$_POST接口里做耗时聚合，否则页面响应直接受拖累 - 时间戳必须由客户端传入（或服务端用
microtime(true)），不能依赖 DB 的NOW()，否则跨服务时序错乱 - 关键字段如
uid、event、page、duration（停留秒数）建议统一 JSON 化后存，方便后续扩展
标签怎么打：用「窗口聚合 + 规则引擎」代替硬编码 if-else
直接写 if ($clicks > 5 && $stay_time > 60) { $tags[] = 'high_intent'; } 看似简单，但规则一多就失控——运营要改个「7 天内点击商品页 ≥3 次才打兴趣标签」，就得改代码、发版、重启。
更可持续的做法是把标签逻辑配置化：
立即学习“PHP免费学习笔记（深入）”；
// tags_rules.json 示例
{
"interest_goods": {
"window": "7d",
"condition": "SUM(CASE WHEN page LIKE '%product%' THEN 1 ELSE 0 END) >= 3",
"source": "behavior_log"
}
}
- 用
PDO::query()执行带WHERE uid = ? AND ts >= ?的聚合 SQL，避免全表扫 - 窗口时间（如 7d/30d）必须转成绝对时间戳计算，别用
DATE_SUB(NOW(), INTERVAL 7 DAY)，否则跨时区或 DB 主从延迟时结果漂移 - 对「停留时长」这类需要前端上报的数据，服务端要校验合理性（比如
duration > 3600就丢弃，防恶意刷）
画像怎么存：别把标签当字符串拼接进 user 表
很多人图省事，在 users 表加个 tags 字段，存成 "interest_news,high_value,visited_cart"。这会导致查「所有高价值用户」时只能 LIKE '%high_value%'，无法走索引，且更新冲突风险高（两个进程同时读-改-写）。
正确姿势分两层：
- 标签元数据存在
user_tags表：uid、tag_code（如interest_news）、weight（置信度，如点击频次归一化值）、updated_at - 常用组合标签（如「近 7 天活跃 + 高停留 + 有加购」）可预计算到
user_segments表，供业务快速 JOIN - PHP 写入时用
INSERT ... ON DUPLICATE KEY UPDATE，主键设为(uid, tag_code)，避免重复插入
PHP 聚合脚本容易崩在哪几个点
跑定时聚合的 PHP CLI 脚本（如每小时跑一次），最容易在三处挂掉：
- 内存溢出：用
yield流式处理大结果集，别fetchAll()全捞进内存；查 100 万用户？分页用WHERE uid > ? LIMIT 1000滚动查询 - 超时中断：CLI 默认
max_execution_time=0，但 MySQL 连接可能被wait_timeout干掉，记得在循环里定期$pdo->query('SELECT 1')心跳保活 - 并发打架：多个实例同时处理同一时间窗口，用 Redis
SETNX加分布式锁，key 命名为agg:tags:20240520_09这种带时间戳的唯一标识
标签不是静态快照，而是随行为流持续演化的状态。最常被忽略的是「标签衰减」——上周频繁点击美妆的用户，这周没任何动作，interest_beauty 的 weight 应该按天衰减，而不是一直挂着。这点 PHP 层得在每次聚合时主动计算，不能靠数据库默认值撑着。
