ASP.NET Web Api如何留存前置请求值实现会话状态管理

核心问题拆解 #

这是典型的短周期会话状态管理问题，不需要把所有请求值全量持久化，按数据生命周期分层存储即可，先明确两个基础疑问的实现逻辑：

• 菜单节点识别逻辑：绝对不能单独靠用户回复的数字做路由判断——数字只是当前菜单下的选项映射值，脱离当前菜单上下文没有任何意义。所有路由判断必须先绑定用户唯一标识查询当前所处的活跃菜单节点，再将用户回复的数字匹配到对应节点下的选项，从根源避免用户随意回复数字导致的路由错乱。
• 上下文传递逻辑：不需要在WhatsApp回调链路、API请求里透传菜单标识这类上下文参数，所有上下文统一存在服务端，API内部处理时直接通过请求携带的用户唯一标识拉取对应上下文即可，既避免参数被篡改，也减少链路传参的复杂度。

存储方案选型 #

不需要在数据库和缓存方案中二选一，两类存储搭配使用性价比最高：

• 缓存存临时活跃状态：菜单交互属于短周期行为，绝大多数用户的菜单操作会在15-30分钟内完成，超时后自动回到根菜单即可，这类热数据用Redis类内存缓存存储最合适，性能足够高，还支持自动过期清理，不需要手动处理无效状态。
  缓存key按固定规则拼接即可：whatsapp:user_session:{whatsapp_user_id}，value存储结构化的会话状态，示例结构：

  {
    "current_menu_id": "complaint_sub",
    "previous_menu_id": "main_root",
    "selected_biz_params": {},
    "last_interact_time": 1718000000
  }
  

  每次用户触发有效菜单跳转时，更新对应缓存内容，同时重置过期时间即可。
• 数据库存永久留痕数据：如果业务需要审计用户操作路径、留存用户提交的投诉/账单查询等正式业务数据，再将这类需要长期保存的数据落关系型数据库即可，中间的菜单跳转临时状态不需要落库，避免产生大量无价值的冷数据占用存储。

落地实现步骤 #

• 1. 以WhatsApp官方返回的用户全局唯一ID作为会话关联键，不要用手机号作为关联标识，避免用户换绑手机号导致的状态错乱。
• 2. 用户首次发起会话、缓存状态过期失效时，初始化会话缓存，默认当前菜单节点为主菜单，设置30分钟过期时间，后续每次用户产生有效交互就刷新缓存过期时间。
• 3. 收到用户回复消息时，先通过用户ID查询缓存拿到当前菜单节点，再匹配用户回复内容是否属于当前节点下的有效选项：比如当前在主菜单节点，用户回复1，就将缓存中的当前菜单节点更新为投诉子菜单，返回投诉子菜单的提示文案；如果当前在投诉子菜单节点，用户回复1则路由到发起新投诉流程，回复2则路由到投诉列表查询流程。
• 4. 加异常兜底逻辑：如果查询不到用户的有效缓存，直接返回主菜单提示；如果用户回复内容不属于当前菜单的有效选项，直接返回选项错误提示，不更新缓存中的会话状态，避免流程断层。
• 5. 如果需要统计菜单转化率、用户操作路径这类分析数据，异步将菜单跳转记录写入数据库即可，不要同步写库影响接口响应速度。

内容的提问来源于stack exchange，提问作者Abdul Aleem Solutions