javascript 中的 session 不直接存储试听权限，需前后端协同：前端用 sessionstorage 缓存会话内状态（如试听时长），后端通过 session/token 校验真实权限并动态返回受控播放资源，关键逻辑必须在服务端实现。
JavaScript 中的 Session 本身不直接存储“试听/试看权限”，它只是浏览器提供的一种短期状态管理机制（sessionStorage 或服务端 session）。真正实现试听/试看权限控制，需要前后端协同：前端用 sessionStorage 缓存用户当前会话内的操作状态，后端通过 session 或 token 管理真实权限逻辑。
用 sessionStorage 记录本地试听/试看次数
适用于“单次会话内最多试听 3 分钟”这类轻量级限制。页面刷新后重置，适合临时体验场景。
- 播放器初始化时，从
sessionStorage读取已用时长或次数：sessionStorage.getItem('trialUsedDuration') || 0 - 监听
timeupdate事件，累加已播放秒数，并实时写回：sessionStorage.setItem('trialUsedDuration', current + 1) - 达到阈值（如 180 秒）时，暂停播放、禁用进度条、提示“试听已结束”，并可触发跳转购买页
结合后端 Session 校验播放请求
更可靠的方式是每次播放请求（如获取音视频 URL 或解密密钥）都由后端鉴权。前端只负责传递凭证，不自行决定是否允许播放。
Ai Coach Batch Session Summary
下载
批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。
- 用户点击播放时，前端携带当前 session ID（通常已存在 Cookie 中）或 JWT Token 向后端请求播放凭证
- 后端检查该用户本次 session 是否有剩余试看额度（例如数据库中记录
user_id + session_id + used_seconds） - 若允许，返回带时效签名的播放地址（如 S3 presigned URL）或 AES 解密密钥；否则返回 403
避免绕过：关键逻辑必须在服务端
前端任何判断（比如隐藏按钮、禁用控件）都可被开发者工具绕过。真正起作用的是后端对媒体资源的实际访问控制。
- 不要仅靠 JS 判断是否显示“立即开通”按钮——它只是提升体验，不是安全边界
- 音视频文件不应放在公开静态目录下，而应通过受控接口（如
/api/play?trackId=123）动态返回，且每次请求都校验权限 - 可配合时间戳+签名防止 URL 被复用，例如后端生成链接时附带
?t=1717023456&sig=abc123，超时或签名失效即拒绝响应
补充：区分“试听”和“已购”的状态同步
用户购买后需及时清除试用状态，并更新播放器行为。推荐使用事件驱动方式同步：
- 支付成功回调中，调用后端接口标记订单生效，同时向当前页面 postMessage 或触发自定义事件
- 播放器监听该事件，清空
sessionStorage中的 trial 相关字段，并重新请求无限制播放地址 - 也可用 BroadcastChannel API 在多个同源 tab 间广播状态变更，确保权限实时生效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
