Google App Scripts同用户跨脚本访问User Cache返回null问题

读取缓存返回null由两个独立原因导致：

• 键名大小写不匹配：Cache Service的缓存键严格区分大小写，写入时使用的键是FirstName（大写N），读取时传入的键是Firstname（小写n），键名不一致无法命中缓存。
• User Cache原生作用域隔离：这是跨脚本读取失败的核心原因。CacheService.getUserCache()的访问权限严格绑定「单个脚本项目+单个访问用户」，属于脚本私有缓存，两个独立部署的Web App属于不同的脚本项目，哪怕是同一用户访问，也无权读取对方写入的User Cache，这是平台的固定隔离规则，没有配置项可以放开跨脚本访问权限。

注意Cache Service本身是临时缓存，未手动设置过期时间的内容默认仅保留10分钟，最长存储周期也不超过6小时，本身就不适合存储需要跨应用读取的用户提交数据。

根据业务场景可直接选用以下方案：

• 共享存储表方案（适合正式生产场景）
  新建一个Google Sheet作为公共数据存储表，给两个Web App对应的脚本项目都授予该表格的编辑权限：
  1. 部署Web App时，将执行身份设置为「以访问用户身份执行」，确保脚本可以通过Session.getActiveUser().getEmail()获取当前用户的真实邮箱，作为用户唯一身份标识
  2. 第一个Web App收到用户提交的个人信息后，以用户邮箱为唯一键，将FirstName、Surname等字段写入共享表格的对应行
  3. 第二个Web App被访问时，先获取当前登录用户的邮箱，到共享表格中匹配对应行的字段即可拿到数据
     该方案存储的数据无过期时间限制，可持久化保存，稳定性最高。
• 同项目合并方案（适合业务耦合度高的场景）
  如果业务逻辑允许，把两个Web App的代码整合到同一个Apps Script项目中，通过URL参数（比如?page=submit、?page=result）区分不同页面的返回逻辑。同个脚本项目下，同一用户的User Cache完全互通，修正之前提到的键名大小写错误后即可正常读写。
• URL传参方案（适合非敏感数据临时跳转场景）
  如果用户操作路径是第一个Web App提交后直接跳转到第二个Web App，可以在拼接跳转链接时，把需要传递的非敏感信息作为URL参数附带在跳转地址后，第二个Web App直接从请求参数中解析对应值即可，无需依赖缓存服务。注意该方案禁止传递身份证、密码、财务信息等敏感数据。

内容的提问来源于stack exchange，提问作者David Howarth