问：什么项目用 gon 最值？
最值的场景是传统 Rails 项目：页面主要由后端渲染，前端只负责图表、筛选、按钮交互这些增强功能。你不想为几个初始字段多写接口，也不想在 ERB 里拼 JavaScript，gon 就能省下不少胶水代码。
比如后台首页要把今日订单数、待处理工单数、当前用户角色传给前端图表。数据页面打开时已经算好了，gon 一次带过去，比再请求一个 /dashboard.json 更轻。
gon值得吗：一张清单说清楚
gon值得吗，得看你的项目是不是刚好卡在“Rails 页面要给 JS 一点初始化数据”这个位置。它不是越多越好，也不是用了就落后。下面用问答清单把适合、不适合、成本和替代方案拆开说。
问：什么时候不值得？
如果你的前端是完整 SPA，路由、数据、权限都由接口驱动，gon 的价值会变低。因为你真正需要的是稳定 API，不是一页 HTML 里顺带塞变量。
还有一种不值得：团队没人愿意定规则。今天把用户信息放 gon，明天把订单列表放 gon，后天把权限矩阵也放进去，很快就会变成一个谁都不敢动的全局对象。工具没错，用法失控才麻烦。
问：它能省多少事？
省的不是大工程量，而是小摩擦。少写一个初始化接口，少处理一次加载态，少在模板里手写 JSON 转义。对后台系统来说，这些小地方积起来挺明显。
我通常会用一个判断：如果这个数据只在首屏用一次，而且页面渲染时后端已经拿到了，那 gon值得吗？大概率值得。反过来，如果数据要频繁刷新，就别勉强。
问：会不会影响代码质量？
会，取决于你怎么约束。好的写法是给 gon 变量起清楚的名字，比如 gon.chart_data、gon.current_permissions。差的写法是 gon.data、gon.info、gon.temp，三个月后没人知道里面是什么。
还有一点很实用：不要传 ActiveRecord 对象本体，自己组 hash。字段越少，风险越低，前端越好读。gon 本身不能替你判断哪些数据该公开。
问：最后怎么决策？
把问题缩成三句：页面是不是 Rails 服务端渲染？数据是不是首屏初始化就要用？数据是不是页面渲染时已经在后端手里？三个答案都是“是”，gon 就值得试。
如果只有一个“是”，我会优先考虑 data 属性或 API。gon 的好处来自边界清楚，一旦边界模糊，它省下的时间会在调试和重构时还回去。
推荐阅读
常见问题
- gon值得吗，新项目还需要用吗？
- 如果新项目是 Rails 服务端渲染并带少量 JS 增强，值得；如果是纯前后端分离项目，优先设计 API。
- gon 会让前端变乱吗？
- 无规则使用会乱。建议只放页面初始化数据，命名具体，字段最小化，不把 gon 当全局数据库。
- gon 和 ViewComponent、Hotwire 冲突吗？
- 不冲突，但用途不同。Hotwire 更偏交互更新，gon 更偏页面初始数据传递。能用 HTML 表达的就别硬塞 gon。