cf worker 可以反代，tos 里只写了禁止用于非法活动等，加下验证别开匿名使用就行，搜下相关案例都是被投诉用于欺诈的，只要别人不能用就不会被当成钓鱼站点了

@ThinkStu #24 害，还以为是啥呢，这不是你自己披露的嘛，知道你 v2 的帐号的人都能把这两者联系起来，这能算开盒嘛？
根据你的截图，直接事实只有当事人发错了链接并撤回，实际上想发的是有关沉浸式翻译争议的帖子 https://www.v2ex.com/t/1042477 ，曝光隐私是你的揣测。
V2 地址辨识度低，手滑发错了过了一会儿才反应过来撤回也合情合理（至于复制错的原因，如果是看过往发言查成分说实话也正常，V2 不会隐藏二手交易的帖子，如果你限制了发帖查看，那二手相关帖子就变成唯一能看的新开帖记录了）。就算他从来没发错过，从后面新链接过来的人依旧可以从你个人主页里找到那条二手交易，把这当成曝光隐私有点小题大作了

单独说下第一点，他并不是假开源，而是先开源后闭源，和其它知名工具的不同之处在于，他用了一个新的闭源版本相关的仓库替换掉了原本的开源仓库，原仓库被改名了（不用说大家也知道是一步臭棋），同时在新仓库里并没有说明这一点，导致很多人没发现新仓库其实不是开源的那个版本，就比如你提到的那个帖子的楼主。

开源源码在 https://github.com/immersive-translate/old-immersive-translate ，
3 年前归档，你去 webarchive 能看到 23 年 2 月以来一直可访问，帖子 23 年 8 月，所以其实是帖主搞错了

顺便贴两个链接：
稍早一些的帖子 https://www.v2ex.com/t/1151127
应该是作者本人的回应 https://www.v2ex.com/t/1151145

大家都在往坏的方向解读：你禁止第三方 api key 是为了推广收费服务。
你需要专门针对这个视角回应一下。

如果单纯是为了防止小白被骗（但这实际上不是你们应用的问题，你们也不应该因此影响其它正常用户的使用），
需要解释下为什么没有采取温和或者折中的方案（非常明确的提示或警告，通过隐藏开关启用等等）。

任由事态发展的话恐怕要覆水难收了

https://github.com/microsoft/vscode/issues/260389#issuecomment-3166309726
等这个 issue closed 再升吧

@shintendo #4 这瓜好像听过，但印象不深，刚才去回顾了下。现在突然发现，前几天某个帖子颇有种 deja vu 的感觉啊哈哈

游戏开发哪里到那么底层，顶多考虑下用 TCP 还是 UDP

楼主想问的是 SSR 里的水合吧（ Hydration ），服务端返回渲染完的 html ，在客户端根据 html 内容将组件和 DOM 一一对应并绑定事件等。水合基本上是前端框架主导的，后端只需要提供 html 和所需相关信息。

也就是说，如果你想实现 SSR/基于 SSR 的 SSG ，你得找到一个支持 SSR 的组件框架，基于 JS 的有 vue, react, svelte, solid, angular 等等，Laravel 文档的 SSR 说明里提及了 Inertiajs https://laravel.com/docs/12.x/vite#ssr 。

想了解 SSR 原理可以看看 vue 的文档 https://cn.vuejs.org/guide/scaling-up/ssr
以及 vite 的文档 https://cn.vite.dev/guide/ssr.html

因为 vibe coding 和 AI 辅助编程就不是一回事
用 vibe coding 描述时，当事人是不会去看具体代码的

有人专门就两者被错误混用一事写了条博文
https://simonwillison.net/2025/May/1/not-vibe-coding/

@Immortal #8 https://ui-libs.vercel.app/

你问机场客服有什么用，你找淘宝卖家客服问淘宝 app 技术细节他能知道吗，clash 的技术细节为什么不看 clash 的文档/源码而去问机场，多数机场的网站后端基本都是套的现成模板，不参与客户端开发更别提内核了

vscode 因为内存占用比较高，扩展一多就容易有扩展被挤掉（建议语言类扩展默认关闭，根据项目单独开启），CTRL+SHIFT+P 打开命令面板，一般有三种重启方式：
- 通过扩展自身的命令重启该扩展，例如 Restart XXX language server ，当然如果扩展自己爆了就得用后面的方式。
- Restart Extension Host ，会重新加载所有扩展，vscode 自身进程保持不变，可以解决大多数加载异常问题。
- Reload Window ，会连带 vscode 一起重新启动

此外，当前版本的 vscode 有内置的行内 git blame 提示，默认关闭，需要手动开启：
打开设置，搜索`@id:git.blame.editorDecoration.enabled`
（如果你想关闭 gitlens 的，搜索`@id:gitlens.currentLine.enabled`）

https://x.com/yuxiyou/status/1941079033049162012

大概相当于，村里大学生迁户口了

楼主想复杂了，我去搜了 kingdom rush 的视频，特斯拉塔的闪电压根就没考虑过变形的问题，就是单个素材重复使用，https://www.bilibili.com/video/BV1g14y1t7CK?t=1807.8 30:08 这里，右上角那个怪丝血被最近处电塔打时，闪电都缩到看不见了，相比正常情况变形很明显吧，但是 0 人在意，楼主练手作品更不需要在意这些细节

优点是比较出来的，vue3 优点在于更灵活，具体怎么做取决于开发者，vue2 时代 options API 很多地方是强耦合的，响应系统严重依赖于组件实例，this here this there ，vue3 我都几乎没见过 this 了

迷茫时可以看看 VueUse ，Composable 的标杆

#20
> 或者说你们真的很喜欢那种 useXXX, 然后导出 8/9 个参数的写法?
先不说有没有必要都放在同一个 composable 里，觉得返回值用解构式声明太多你可以不写解构声明，就用 reactive 包起来，例如`const mouse = reactive(useMouse())`，也是官方推荐的写法

跟特定语言相关的一般是扩展进程挂了/启动失败，不一定是 vscode 的原因

游戏引擎大体上就是前端宿主+游戏相关 SDK+编辑器，
godot 是通用游戏引擎，2D 3D 什么都能做，还有用它来开发软件的（例如 MaterialMaker 和 CozyBlanket ），优点就是经验可以沿用到下一个项目，网络学习资源相比几年前也多了不少，包括国内外。用 godot 时不想写 gdscript 也可以写 C#，godot 很重视对 C#的支持。
另外两个通用游戏引擎，UE 做小游戏属于杀鸡用牛刀了，而且没有网页导出。
Unity 日薄西山，近期几乎没有什么正面新闻，再加上国内运营纯粹添堵的，你下一个非特供官方编辑器都要折腾半天，Unity 的独立开发者群体在逐渐向 godot 迁移。

其它的第二梯队引擎普遍没那么泛用，都有那么几个比较关键的缺点，导出平台受限/仅支持 2D 或 3D/游戏 genre 相对固定/教学资源少文档不完善，不太推荐使用，不过有的引擎也出现过独游神作。属于上限高下限低很看个人操作。
（顺便说下很多收费游戏引擎在 Steam 也有卖，就比如那个 RPG maker 系列，旧版史低时很便宜，官方主要靠卖资产包 DLC 。不过它主要是开发 topdown 回合制的 RPG ，如果你对游戏玩法有更多想法就不太适合。）

如果你已经计划好了游戏最终成品是什么样的，会用到什么功能，那么秉持 MVP 原则，用自己熟悉的语言和开发库，加上一些第三方编辑器，拼个自制引擎来开发也未尝不可。可以看下这篇文章： https://noelberry.ca/posts/making_games_in_2025/ ，蔚蓝的主程写的。

@drymonfidelia #8 如果你说的是图层优先级，单纯让衣服显示在人物前面，那么确实能做，但也只是视觉上的掩耳盗铃，真穿模时该有问题还是有问题，因为本质上并没有解决穿模的问题（也就是物理空间冲突），只不过穿模时不显示交叉部分而已。（更别提这个 hack 可能带来的更多问题）

以及这样实际上不是“内/外”的关系，而是“前/后”的关系，要判断内外必然涉及到碰撞检测相关概念，然后就是大家说的情况

如果你想解决的问题，实际上是你另一个帖子里关于角色/人物几何体绑定动画导致穿模的情况，那么应该是 3D 建模软件的相关问题，跟游戏引擎关系不大，没人会把角色全身的布料都放进游戏物理引擎里，个别组件例如衣摆穿模一下也无伤大雅（此时碰撞也都是和物理引擎的刚体碰撞，不是和人物网格体碰撞），贴身部分可以直接烘培进动画。
最简单的就是那个帖子里 1L 说的，衣服里面完全看不到的面直接隐藏/删除就行了，“某个角度看到是空的”——但能让玩家看到里面本身就是个问题（袖口领口之类的贴合一下，或者用内衬填充，或者只显示入口一小段然后过渡到全黑挡住，类似枪口。）。其它方法还有 shape key 微调等。
以及 V2 上基本都是程序员，你很难找到 3D 资产创作方面的专业答案，建议去行业论坛，或者直接搜，常见问题基本都能在视频网站上找到解决方法。（以及现在有 AI 了可以直接问 AI ）

再说回原来的标题，“永远”“彻底”等绝对词，让人以为你要在物理引擎中完美模拟双方来解决布料网格体与人物网格体穿模的问题。而实时计算下无微不至的模拟，在正常程序员眼中基本等于创造永动机