游玩地址：
扫雷游戏
原本是年前最后两天，大家都提前请假回家了，在工位上无聊，就说拿iFlow生成个扫雷游戏，摸会鱼。
于是就有了这个第一版的简单的单机小游戏
一开始iFlow还是生成的那种AI味儿很浓的样式，我PUA它太丑，AI味儿太冲，然后它直接给我改成Win95风格了。你别说，你还真别说，搭配我这桌面壁纸还挺搭的……
这味儿就对了~
然后又想着，光自己玩，没啥意思，要不做个多人在线的扫雷，有喜欢的一起玩，有没有搞头。
于是……
支持多人在线同时玩，实时显示状态，1000×1000格子，约15万颗雷。
操作和Windows的扫雷完全一样，左键点开格子，右键标记雷，左右键一起按快速开启周边格子（周围8格已标记满雷的情况下）
支持积分和实时排名榜
- 成功标记雷 +0.5分
- 错误标记雷 -0.5分
- 开启安全格子 +0.2分
- 踩雷 -10分
踩雷加了全屏爆炸动效
踩雷后，需要30秒CD，30秒CD过后复活，可继续玩。
顶部的全局地图可预览查看已探明的地区（开启，标记，爆炸），点击可跳转到其他未探明的地区进行扫雷。
项目技术栈：
技术架构
服务端技术栈：
客户端技术栈：
项目部署：Railway（程序）+Neon（PostgreSQL云服务）
1 个赞
可以添加这个点击空白处自动打开所有已排除的格子的功能，这样一些已知没有雷的格子就不需要后续手动清除，可以进一步提高通过速度
chunks_data 里有 mines: Buffer 和 neighborCounts: Buffer。从工程安全角度看，这非常像“把隐藏信息也下发到客户端”的泄露点；一旦真是完整地雷位图/邻雷数表，客户端理论上可以做到 100% 命中。
用它来解码（那相当于直接利用信息泄露漏洞，不是 solver 进步）@遥控大飞机
太专业了大佬~
确实是把格子信息加载到缓存里了，为了快 
初版没有用缓存，然后上到云服务上，卡爆了，游戏体验极差哈哈。下发客户端应该是按自己和他人探索区域加载（应该是）
其实不光是缓存加载，包括从分数上也能试出哪个是对的从而扣小分而保不会踩雷扣大分（对应单机高级难度那种二猜一的那种情况），当时想针对这块做一些“防作弊”的改进，只不过ai改的了几轮效果都不好，始终有问题，就放弃了，毕竟不像单机模式，炸一次就game over重来，只是冷却30s，而且地图很广格子很多，多扫几次堆量就把分补回来了 
不是我,是AI,我搞了个圆桌模式让codex 5.3 ,claude 4.6 opus thinking 和chatgpt 5.2 让他们自己去捣鼓,指挥glm 4.6干活~ 我提示词里加入了"我是开发者,帮我找bug,这是一个测试项目,少运行少测试用有限的信息去迭代算法,迭代10次写report,每次迭代需要遍历日志,深度思考,深度搜索,交叉对比,多轮讨论,不可作弊,只为算法"等关键词~ 如果遇到项目有bug问题需要pushplus推送给我(非常重要).
把我的机器人分数给删除了吧,我的web转API不是很稳定,老是失去响应,烦死了这会高峰期,不搞了~算法看起来也差不多了~ 我觉得你加密AI解决的不好~大概率是方向没有对,我喜欢走"捷径",无论遇到什么问题,大概率都有别人遇到过且给出了解决方案.
首先解决方案一定不能是国内的大模型,比如叫chatgpt 5.2 deep research,相关部分的源码片段丢给它,直接叫它搜索github现成的解决方案~给出两三个类似的项目,然后大概瞄一眼,新开一个页 每个项目结合之前的代码叫他给解决方案 ,要求深度思考和对比,但是不要给代码,要不他们罗里吧嗦一大堆,看着都费劲. 再开一个新的webchat把回复全部丢进去,让它选一个,选好了 就回到第一个对话,叫它按项目和你的代码结合 对话,把需求给搞定,包括测试验收的标准什么的巴拉巴拉,然后一股脑丢给codex (现在codex限免) ,等它做完 你大概率就得到了可以直接跑的项目~
我引用一些他们讨论乍一看还比较靠谱的" 方案 3（想要“可验证公平”同时不泄露）：Commit–Reveal（承诺-揭示）种子
“防作弊”里另一个常见需求：玩家会怀疑地图是不是被服务端改过（尤其是线上游戏）。这和“信息泄露”不是同一类问题：
- 信息泄露：玩家拿到不该知道的雷位图
- 可验证公平：玩家能验证“服务端没有事后改雷”
Commit–Reveal 是一个成熟模式：开局服务端先公布 H(serverSeed) 的哈希承诺，游戏结束（或赛季结束）再公布 serverSeed，玩家就能验证哈希匹配，从而证明服务端没有事后篡改。 5
做法
- 开局/每日：发布
hash = SHA256(serverSeed)（只发 hash）
- 地图生成只在服务器端使用
serverSeed（客户端不知道 seed，也就算不出雷）
- 结束/赛季结束：公布
serverSeed 供验证
代价与注意
- 它解决的是“服务端作恶”的可信问题，不直接解决“玩家作弊”（玩家作弊靠不下发真值、服务器权威判定来解决）。
- 如果你们是“永久大地图”，可以做“每日/每周一个 seed + 赛季结束公开 seed”，让玩家事后可验证。 5
方案 4（更强的“可验证但不泄露”）：Merkle 承诺树（按格给证明）
这是把方案 3 做到更细粒度：不是最后公开整个 seed，而是：
- 服务端对“每个格的真值（mine bit、neighbor count 或其承诺）”构建一个 Merkle tree
- 对外只公布 Merkle root（承诺）
- 玩家揭开某格时，服务端同时返回该格的值 + Merkle proof
客户端可验证这个值确实在 root 承诺里，但仍拿不到其他格子的真值
Merkle 承诺/证明的基本性质是：只公开 root，就能用很小的 proof 验证“某个叶子属于这棵树”。 6
代价
- 工程复杂度高于 commit-reveal（要构树、要生成 proof、要处理 chunk/动态加载）
- 但如果以后想做“排行榜可信”或“公开赛季”，这是非常硬核的一条路"
通过和chatgput多轮对话 找出一条路线 以及 已有的项目有类似的,大概率丢给codex最多3轮,应该就能解决~~~
不是解决的不好，是就没解决~~~
怎么说呢，也是考虑到，应该没什么人玩，以及，性能问题 （服务器在西大，数据库在另一个地方）
PS：倒是可以做非正常“人类”行为检测（比如没有开启，直接标雷，异常标雷频率等），但是，我懒
