窗口函数计算LTV必须用ORDER BY时间字段（如order_date）实现逐行累积，而非仅PARTITION BY；默认窗口范围是ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW；需清洗数据（过滤空值、退款、重复单），并按业务口径合理设置PARTITION BY维度。
窗口函数必须配合 ORDER BY 才能定义“生命周期”顺序
订单的生命周期价值（LTV）本质是按时间累积客户消费，不是简单求和。如果只写 SUM(amount) OVER (PARTITION BY customer_id)，得到的是该客户总金额，但无法体现“随时间推移的价值增长”。必须用 ORDER BY order_date（或等效时间字段）让窗口从第一单开始逐行累加。
常见错误是漏掉 ORDER BY 或用了非时间字段（比如 ORDER BY order_id），导致逻辑错乱——尤其当订单录入顺序与实际发生时间不一致时。
- 确保排序字段是真实业务时间，优先用
order_date、created_at，而非自增 ID - 注意 NULL 值：若
order_date可为空，需提前过滤或用COALESCE(order_date, '1970-01-01')占位 - 时间精度要统一：避免混用
DATETIME和DATE导致隐式转换后排序异常
SUM() OVER () 的默认窗口范围容易被忽略
很多用户以为 SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date) 就是“到当前行为止的累计”，其实它默认等价于 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW —— 这个行为是对的，但一旦显式写了其他范围（比如误加 ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING），结果就完全反了。
更隐蔽的问题是：某些数据库（如老版本 MySQL）不支持省略范围语法，必须显式声明；而 PostgreSQL 和 BigQuery 则默认安全。跨平台迁移时容易出错。
- 除非有特殊需求，不要显式写
ROWS子句，依赖默认行为更稳妥 - 如需排除当前行（比如算“历史累计，不含本单”），用
ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING - 在 Hive/Spark SQL 中，
UNBOUNDED PRECEDING对应UNBOUNDED PRECEDING，但部分旧引擎不识别CURRENT ROW，建议测试验证
多维度生命周期（如分渠道、分产品线）要小心 PARTITION BY 组合
真实场景中，LTV 往往需要按客户 + 渠道（source）或客户 + 产品类目（category）分别计算。这时 PARTITION BY 必须包含所有分组维度，且顺序无关，但字段选择直接影响结果粒度。
典型翻车点：把 category 放进 PARTITION BY 后，发现某客户在不同类目下 LTV 从零开始算——这其实是预期行为，但如果业务本意是“客户整体 LTV + 类目贡献拆解”，那就该用两层计算：外层算客户总 LTV，内层用 GROUP BY 或子查询做归因。
- 先明确业务口径：“每个客户在微信渠道的累计消费” →
PARTITION BY customer_id, source - 避免在
PARTITION BY中加入高基数字段（如order_id），会导致窗口无法聚合，性能暴跌 - 若需同时看客户级和全局趋势，可嵌套窗口：外层
OVER (ORDER BY order_date)算全站日累计，内层OVER (PARTITION BY customer_id ORDER BY order_date)算个人累计
空值、重复订单、退款单会直接污染 LTV 累计结果
窗口函数不会自动过滤脏数据。如果原始订单表里存在 amount IS NULL、amount = 0（占位单）、或负值（退款单），它们都会参与 SUM() 累加，导致 LTV 曲线突兀跳变甚至为负。
这不是窗口函数的 bug，而是数据建模缺失。生产环境必须前置清洗，不能靠窗口函数“硬扛”。
- 推荐在子查询或 CTE 中先过滤：
WHERE amount > 0 AND order_status IN ('paid', 'shipped') - 退款单不应删，而应单独建表或打标（如
is_refund = true），然后用CASE WHEN调整金额：SUM(CASE WHEN is_refund THEN -amount ELSE amount END) - 对同一
order_id出现多次的记录，务必去重（用ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC)取最新）
