如何声明Shiny中跨所有函数共享的变量及方案对比

绝大多数场景下，第二种基于reactiveVal创建响应式变量的方案更优，<<-父级环境赋值的方案仅适合极特殊场景，常规业务开发不推荐。

选择依据主要有三点：

• 响应式适配能力有本质差距
  <<-是R语言自带的环境赋值运算符，根本不在Shiny的响应式体系设计里。用它修改普通变量时，Shiny完全感知不到值的变动，所有依赖这个变量的输出、计算逻辑都不会自动更新，很容易出“值明明改了但界面/结果没刷新”的玄学bug。你给的示例能跑通，只是因为弹窗是点击按钮时主动触发读n，刚好读到了最新值；如果换成绑定在页面输出上的render*类函数，用<<-改完变量根本不会触发输出重绘。
  而reactiveVal是Shiny原生的响应式对象，只要在render*/observe*/reactive这类响应式表达式里调用n()读值，变量更新时所有依赖它的逻辑会自动重算、界面自动刷新，行为完全符合Shiny的开发逻辑，不用额外写手动触发的代码。
• 作用域安全性差很多
  <<-的赋值逻辑是逐层往上找父环境里的同名变量，找到就改，找不到就会一路创建到全局环境。简单demo里把变量写在server最外层，确实能做到单会话隔离，但一旦代码变复杂——比如写嵌套函数、用循环批量生成逻辑、开发Shiny模块——很容易判错环境层级，把变量漏到全局环境，最后变成多用户共享的变量，生产环境出这种问题就是不同用户数据串改、信息泄露的大事故，排查起来特别麻烦。
  reactiveVal的作用域完全和创建它的环境绑定，在单个用户的server会话里创建，就天然只属于当前会话，不会跨会话泄露，哪怕写嵌套逻辑、开发模块也能精准控制作用域，不会意外污染全局环境。
• 长期可维护性差距明显
  用reactiveVal写的代码，所有响应式状态的读、写都有明确语法标记（读值带()，写值传参），后续迭代、调试的时候很容易定位状态变化的节点；而<<-赋值和普通变量赋值看起来差别极小，其他接手代码的人很容易忽略这是个跨函数共享的变量，误改逻辑。

当然<<-不是完全不能用：如果你要存的变量完全不需要触发任何响应式更新，只是当内部临时标记（比如存个日志开关、临时缓存值），而且能100%确认作用域不会出问题，也可以用。但哪怕是这种场景，用reactiveVal也没什么额外性能开销，实在没必要冒引入bug的风险。

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