cursor 有点蛋疼的是 tab 会无响应，我用自动挡比较少，一半时间是手动挡，刚需 tab 给我写重复性代码，但是偶尔遇到 tab 没掉，只能转自动挡

跨过的路径肯定不算占据啊。
拿笔画了好久，感觉不存在必胜的策略，只要先手能走到中间后手怎么玩。

@Chuckle #39 我想象中的 rustscript 差不多长这样

let a: Owned<string> = "hello"
let b = a
console.log(a) // 编译失败

let c: Shared<string> = "world"
let d = c
console.log(c) // 编译成功

const e = (s: &string) => {}
const f = (s: &mut string) => {}

// 异步生命周期
async function g<'async>(data: &'async data) {}

// 安全访问 dom 元素
document.getElementById("h")?.with_mut(|el| el.textContent = "hello world")

随便找家小公司吧，不过目前就业确实很困难，20 年可以算软件行业最后的辉煌了，现在外边一堆的程序员跟你一样，还在招人的 90%是外包，在 boss 上看过有人连续投了半年都没拿到 offer 的。

我觉得是可持续性迭代

快速产出不熟悉领域的东西还是好用的，第一次用 fabric.js + pixi.js ，文档一点没看半天就把需要的东西写好了。
但是技术债依旧得还，还是慢慢花了 2 天时间把文档看一遍，彻底重构一遍 AI 拉的狗屎代码。
已经可以想象一堆公司都在快速产出大量垃圾了，这倒是没什么，但是管杀不管埋就不好了。

@yikyo #4 个个年薪百万？

应该实现不了，defineXxxx 是编译器宏，会在编译阶段把 setup/props/emits/model 等展开转换成更低级的写法，如果是 TypeScript ，会在这个阶段进行类型检查并生成对应的运行时值。
为了能在编译阶段做这件事，类型必须是静态的(虽然后面开始支持泛型了)，不然编译器毛都找不到怎么给你转换成运行时值。
另外建议不要在 Typescritp 用 enum ，绝大多数场景
'a' | 'b' | 'c' 比
enum BaseEvent {
a = 'a',
b = 'b',
c = 'c',
} 更好，还省去了一堆 import
枚举唯一的好处就是改名不用重构，但这玩意谁没事会去改，经手过几个项目都是枚举用得飞起，我自己写的就完全不用。

又试了下
type Test = 'a' | 'b' | 'c'
type CustomEvent = {
[K in Test]: string
}
defineEmits<CustomEvent>()
这样写是不会有警告的，说明编译器在编译阶段确实拿到了三个字面量，顺利生成代码。不过我懒得检查是否功能正常了，我不会写这种玩意，而且 eslint 会警告要改成 Record ，Record 写法无法通过编译。

AI 作为辅助没毛病啊，检查一下命令效果，总结一下用法之类的。但是敢在生产环境执行一个并不熟悉的命令，或者未认真检查 AI 写的脚本就开 run ，这个人一定不应该拥有生产环境的权限。

我写 java/kotlin 是 cursor 对话和生成，idea 里看代码，不冲突
写其他语言也是 vscode 和 cursor 各开一个

@bronyakaka #7 在实践中，一般会将加密方法放在 wasm 中，然后在 wasm 环境判断当前客户端是否可信，不可信就返回虚假的结果。当然这个理论无法实现，因为所有客户端必然不可信，而且 wasm 几乎获取不到什么关键信息能用来区分是否是恶意调用。这只能给逆向的玩家们增加一点难度，或者说时间成本。如果只能通过特定参数、算法、环境因素等等才能获取到正确结果，那逆向的思路就换成了模拟出这些前置要求，防是防不住的。

是的，并不需要知道它实现了什么，只要找到调用入口就行了。这个逻辑在 js 也是一样。
混淆其实分为两种，混淆调用实现，混淆调用入口。js 层面的混淆同时做了这两件事，破解者要还原逻辑只要耐心点是一定能成功的，本质上是增加了破解成本。但是目前可以通过反混淆工具+AI 轻易还原，至少对我个人来说是没有成本的。虽然混淆后代码是多样的，但是混淆的方案是已知的可预测可学习的，这点是 AI 的强项。
wasm 在这里是增加了阅读调用实现的代价，从高度混淆的 js 转成更难处理的 wasm 文件，但是调用入口无法隐藏，有些时候并不需要知道里面实现了什么逻辑，只需要 hook 调用就行了。
还可以从另一个方向入手，魔改 javascript-obfuscator ，自己实现的 js 混淆 AI 不好还原，因为它的训练材料里没这玩意。这个可以跟 wasm 方案合起来，逆向成本足以让大多数人止步了。
再进一步，实现一个虚拟机，应该是目前最安全的。想给逆向增加多少成本，自己就得投入更多成本，没有上限。

@635925926 #25 0.1.2 版本已经修复了这个问题了。
除此之外还有相关的 3 个 pr ，都是用的 toFixed ，简单易懂可以去除一堆边界条件，但是作者都没有接受，依旧采用土法硬算舍入值。
我对浮点计算没有深入研究，理论上 toFixed 处理 x.xxx9 和 x.xxx0 是完全正确的，而作者看起来似乎在硬扣性能，只有某些条件下才会回退到 toFixed 。
作者的代码实现还有个多余的
if (result === '0') {
result = '0'
}
完全没看懂在干啥
现在我是选了个其中一个 fork ，copy 一下放进 utils 里。

@bronyakaka #3
https://go.dev/wiki/WebAssembly
看了下 go 的 wiki ，起步确实是 2m ，应该是 go 运行时打进去了。
下面有推荐一些减少体积的办法，手动优化几百 k ，TinyGo 可以优化到 10k 。
或者看看 rust
https://github.com/wasm-bindgen/wasm-bindgen

@bli22ard #20
0.3399999999999999 = 0.34 是预期行为，这个库就是用来做这件事的。
这已经是第四遍回答了，当你需要显示/计算标准浮点/decimal 时，请使用原生 js 或者 decimal.js, bignumber.js 。
#16 已经说的很清楚了，这个库的作用是
`解决数字格式化的问题，避免因为精度误差导致显示的数字过长或过早使用科学计数法`。
设计上超过一定数量的连续 0 or 9 会直接截断，很显然这样才能实现 0.1 + 0.2 = 0.3 ，而带来的代价就是无法表达含有超过一定数量的连续 0 or 9 。
这个库的适用场景应该是大屏、统计页面等等各种数据可视化，四位以内小数运算是正确的，连续 0 or 9 超过一定次数就会自动四舍五入，严格计算老实去用 decimal.js, bignumber.js ，这只是解决了非严格 decimal 数据的展示问题，让编写显示浮点计算结果的代码更简单易懂适合人类阅读。

wasm 最安全
没事别玩 js 混淆了，人类很难阅读高度混淆的 js 代码，但是 AI 可以轻松还原语义，js 层面的混淆已经可以说毫无用处了，仅仅是让所有用户打开网站卡得半死而已。js 不会让全球变暖，但是 javascript-obfuscator 会。

@UnluckyNinja #16
我以前项目也写过类似的东西
```ts
function n_str(
value: number,
options: { fractionDigits?: number } = {},
): string {
const { fractionDigits = 3 } = options
const str = value.toFixed(fractionDigits).replace(/(\.?|(?<=\.\d+))0+$/, '')
return str === '-0' ? '0' : str
}
```
toFixed()的问题是无法智能判断精度，需要传入参数指定精度
nstr(1.123456) -> 1.123456
n_str(1.123456) -> 1.123
n_str(1.123456, { fractionDigits: 6 }) -> 1.123456
这里的难点是无法简单判断出浮点数计算的小数位数，比如 0.1+0.2 ，人类都知道应该是 1 位小数点，但是如何从 0.30000000000000004 解析出来，还有科学计数法把这个问题搞得更加复杂，而 nstr 能解决这个问题。手动指定精度 2 行就解决了，为了少写这个参数我不介意在项目里多 install 一个包。

目前 nstr 我测了所有情况，就剩 456.78999999456789=456.78 这个问题，其他的都正常
在 nstr 的方案上使用 toFixed 或许能解决这个问题同时不引入其他边缘情况，例如楼上的 pr
https://github.com/shuding/nstr/pull/2/commits/4713d6447bc8fd3af2e246e63ea2f0edb8445d07

最小成本是找个大学生兼职。
AI 想低成本玩 moba 游戏你先等个十年吧，十年不够就二十年。

现代化 nodejs 已经没这么大了，我打开包含前后端的全栈项目看了下，60 多个依赖包，总大小 358M ，去掉 typescript 还能再少一半。
nodejs 体积庞大的基本都是陈年屎山，而且大概率换个电脑就跑不起来。