第一步：先测它该不该出现
做 gon测评，我不会第一步就装 gem，而是先问页面数据从哪来。后端渲染页面时已经拿到的数据，前端首屏马上要用，gon 才有上场理由。否则它只是把本该清楚的接口逻辑藏进 HTML。
一个典型适用例子是报表页默认筛选条件：当前日期范围、用户权限、图表初始数据。一个典型不适用例子是消息通知列表，因为它会不断刷新，还涉及已读状态，走 API 更干净。
gon测评：避坑版使用流程
gon测评如果只说“安装简单、传值方便”，意义不大。真正该测的是它在项目里会不会失控。我按一次接入流程，把几个最容易踩的坑拆出来：输出顺序、数据范围、命名、缓存和替代方案。
第二步：测输出顺序
第一个坑是 window.gon undefined。很多人以为是 gon 没生效，其实只是脚本执行早了。布局里 gon 输出在后，打包后的 JS 在前，前端一读当然空。
我的检查顺序很固定：看页面源代码里有没有 gon 数据；看它出现在业务 JS 前还是后；看脚本有没有 defer、async 或 Turbo 相关行为。这个坑不用猜，看一次源代码基本就能定位。
第三步：测传了多少数据
第二个坑是把 gon 当垃圾桶。为了省事直接 gon.order = @order，短期很爽，长期很危险。模型字段一多，隐私字段、内部字段、无用字段都可能跟着出去。
测评时我会打开浏览器源代码搜 gon，看里面有没有手机号、邮箱、地址、内部备注、权限原始结构。只要出现前端不需要的数据，就说明边界没守住。正确做法是手写白名单 hash。
第四步：测命名和可替换性
第三个坑是变量名随手写。gon.data、gon.obj、gon.res 这种名字，在单页里还能忍，多几个页面就很难追。好名字应该带页面语义，比如 gon.billing_summary、gon.audit_filters。
我还会看前端是不是到处直接读 window.gon。如果十几个文件都在读，说明依赖散了。更稳的方式是入口文件集中读取，再传给具体模块。以后要换成接口，改动范围会小很多。
第五步：给出测评结论
我的 gon测评结论是：它是一个很适合 Rails 服务端渲染项目的小工具，但评分高低完全取决于团队纪律。安装体验简单，首屏传值方便，这是优点；全局对象、数据泄露、脚本顺序问题，是主要风险。
如果你准备接入，建议先在一个低风险页面试两周，限定只传初始化数据，并把字段白名单写清楚。只要这三点能守住，gon 会让 Rails 页面里的前后端协作轻不少。守不住，就别怪工具背锅。
常见问题
- gon测评下来最大的坑是什么？
- 最大坑不是安装，而是传太多数据。把完整对象塞给前端，容易泄露字段，也会让页面数据边界变模糊。
- gon 适合大型项目吗？
- 可以用，但要有规则。大型项目更要限制变量命名、字段白名单和使用范围，否则全局依赖会越来越难清理。
- 怎么判断 gon 是否已经污染代码？
- 搜 window.gon。如果很多业务文件直接读取它，而且变量名含糊、字段庞大，基本就已经需要收口重构了。