@yeqizhang Windows 的话，推荐下载后改名`dsf.exe`，放到你的 path 里，就可以在 cmd 里执行了。
如果不是特别习惯使用命令行，也可以直接双击执行，就是参数没法调整，而且当前工作目录不好确定。

@oott123 哈哈哈，感谢路过。

@yeqizhang 对我来说，主要是：
* 内网分享打包好的程序 /apk/前端项目；
* 大文件内网传输，比企业 IM 快一些。

@sunwang 他是在说我文章里写的不严谨的地方，我想了一个可能更好的表述：

不过，Composition API 也带来了新的易错点，如果你在 composable 中`watch()`store 中的状态，并且在同一个 view 中的多个组件中都用了该 composable，那么`watch()`及其回调会被调用多次，这往往不是你想要的效果。解决方案是为 composable 提供初始化参数。

@sam014 方便分享下对 composition API 不满意的点吗？

你再测久一些试试看，12M 还太少了。
比如 10 个小时后到了 100M，那才是真的漏了。

Go 1.16 之前，不用的内存还给操作系统的时机都比较延后，你也可以更新版本后试试： https://github.com/golang/go/issues/42330

@shakukansp 在这个情况下 watch store 里的东西就容易重复 watch.
谢谢你帮我澄清了这个问题，我等会改改文章里的说法。

@shakukansp 对，就是你说的后一种情况啦。

@shakukansp 我理解 setup()也是一个生命周期钩子，组件 A 引用 B，B 引用 C，B, C 的 setup()都调用了 useX(), useX()中的 watch 会注册两次。这个和 count 是不是同一个关系不大。
Count 可以是同一个，只要它是包级别的（在函数外面），我用了 store，情况很类似。

我的情况是这样的，A 引用 B，B 引用 C，B 和 C 都在 setup 里 useX()，useX 里有 watch.
@shakukansp

@shakukansp 认真，亲身经历。把 watch 写 composable 里很容易就中招了。

@konakona composition API 出来了，现在业务代码也可以复用了，可能可以让你感觉好一点。

哈哈哈，别这样嘛。

@boblin 有，欢迎投递简历参与内推。

@yuhaoyuhao 这本书是重要资源，但是要干活还是不够的。

@zoharSoul 我第一份工作是前端，哈哈。

@dwk715 长期有效。

@lihongming 入乡随俗嘛，当然你也可以直接说谢谢的。

@lxilu 谢谢，测向是后来想明白你的提示后更正的。