嘿，r/Devvit！我的应用这周通过审核并上架后，我想分享一下我开发的内容以及那些我希望早点知道的事。

游戏： r/dashgrid —— 每天UTC时间上午9点，会发布一个新谜题：画一条从绿色起点到红色终点的路径，不能穿越墙壁；步数最少者获胜。周一相对简单，是6×6网格；周六则是残酷的10×10。解谜后，你会看到一张显示所有玩家被困位置的热力图，还有连续天数、每日排行榜以及可选的金币道具（提示、撤销、主题）。

试试看： r/dashgrid · 应用列表：developers.reddit.com/apps/dashgrid

技术栈： Devvit Web —— 客户端使用React + Tailwind + Vite，无服务器后端使用Hono + tRPC，成绩和连续天数使用Redis，金币商店使用Reddit支付。

一路学到的经验：

  1. 根据日期生成谜题，而非存储它们。 通过以日期为种子的确定性生成器，全球每位玩家都能获得相同的网格，昨天的谜题仍可计算用于重玩，而我无需存储任何东西。这是我整个应用中最喜欢的架构决策。
  2. 确保发帖操作三次幂等。 应用通过三种途径创建每日帖子：安装触发、上午9点的定时调度以及紧急情况下的管理员菜单按钮。一个按日计算的Redis键防御所有三种途径，因此无论谁触发什么，都不会重复发帖。
  3. 保持内联（启动）视图极度轻量。 所有重量级内容都放在展开视图中；信息流预览只显示谜题名称和一个“开始”按钮。信息流滚动速度比我预想的更重要。
  4. 在审核前测试支付边界情况，而非之后。 我的“重复购买主题”bug只在真实流程中才暴露——值得尽早强制触发失败模式。
  5. 那20%无聊的工作真的很花时间： 应用目录列表、隐私/服务条款页面、营销网站、子版块品牌、欢迎帖、规则。请为此预留时间——正是这些让应用感觉像产品而非演示。

下一步： 观察第一个完全自动运行的星期，然后根据热力图数据迭代难度平衡（我已经能看到哪些错误转弯坑害了最多玩家）。

很高兴回答任何关于构建的问题——如果你玩今天的谜题，手下留情；今天可是轻松日。🧩