请教一下这种平台国内的目前的审核要求严格吗

不是的哦，wasm 本身没有网络能力，他只能调用 JavaScript 的 API。

在这里打断点就可以看到它实际上的调用是 Go 语言帮你做了一层编译，类似把 net/http 包编译成了 Call("fetch")，本质上还是调用 JS、然后把网络请求的结果变成 uint8 数组进行传递。

客户端可以，浏览器不行的

回答一下第三个问题。wasm 现在在前端运用的其实比较少。

前端说白了其实就是操作状态、渲染 UI。

什么是状态？例如一个 Switch 开关是开还是关；一个 Button 是被 hover、被 click、loading 中、disable 中；你的用户列表展示哪些用户，他们的名字、头像都是什么……这是前端最常用到的状态。

怎么操作 UI？通过 DOM 操作，比如最常用的操作，做一次网络请求，修改按钮的状态：

function submit() {
  const button = 找到 Button
  button.设置为 loading
  button.设置为 不可点击
  request API
  button.设置为 正常
  button.设置为 可以点击
  // ...
}

WASM 的优势是在计算上比 JS 更快，但是他的局限在与无法操作 DOM，目前只有 JS 可以操作 DOM，上面的函数无法用 wasm 写出来。

那我们在关键计算上可以用 wasm 吗？可以，但是 99.9999% 的情况下都没有必要。

第一个问题是，JavaScript 目前的主流引擎都内置强大的 JIT 系统，尤其是 chrome 的 v8，它可以让 JS 的热点代码拥有强大的性能，而 wasm 是没有的。绝大部分前端执行的计算都是短暂的，在 JIT 的加持下，二者的性能差距其实非常小。即使真的有耗费时间的计算，我们也可以利用 WebWorker 来启动工作线程处理，让计算不阻塞 UI。

第二个问题，传递参数给 wasm 的时候有转化成本，你传入的数据越大，转化成本就越高，并且 wasm 不能进行网络请求，你只能从外部传入数据。到最后会发现，这个性能损耗，还不如直接写 JS。

wasm 现在在前端有哪些应用呢？（服务器端其实也有应用，但我不太了解）

1. 大文件处理，例如处理一个上 G 的文件，计算 md5。
2. 底层有非常成熟且复杂的其它语言的库，例如 PS、PR，这些软件底层有大量 C++ 写的库，用 JS 全部重写成本太高了，目前很多 Web 版本的 PS、PR 都使用了 wasm 来迁移这些底层库。

120 也太夸张了，但即使是 120 张页面，前端的异步加载做好、状态管理拆分一下，不会这么夸张的。除非用户在不刷新的情况下，把所有的页面、所有的组件都访问一遍……

另外微前端不是用来解决性能问题的，主要是解决工程问题的，可以看看 qiankun 的文档上描述自己的核心价值是什么 https://qiankun.umijs.org/zh/guide#%E4%BB%80%E4%B9%88%E6%98%AF%E5%BE%AE%E5%89%8D%E7%AB%AF。

其实没有那么夸张，目前最新的 Chrome 可以实时显示每个网页的内存消耗了，目前我们这边最复杂的后台（5000 个组件，30 多个页面，前端路由，redux 全局状态管理），用一段时间后大概也就只吃了 400M。Electron 这种技术主要是包了个浏览器，确实内存杀手，但光页面内存的消耗在今天看来其实真的还能接受。

武汉确实之前传销公司比较多，光谷那一片，好多年没回去了，不知道现在怎么样

复杂组件用 stimulus 太难实现了，特别是现在很多前端项目动辄上千个组件，不用 React/Vue/Solid 这种声明式前端 UI 库根本 hold 不住。但我觉得 DHH 会说：“为什么不保持简洁的前端页面？”

现在很多项目，特别是中后台，PM 对前端组件的复杂度无节制的依赖和设计，确实是搞得大家都很痛苦——运营学习成本高，研发开发成本高。

像 Vue、Solid、Svelte 这种编译更重的框架，做的事情就更多了，比如 Svelte：

<script>
    let count = 0;

    function handleClick() {
        count += 1;
    }
</script>

<button on:click={handleClick}>
    Clicked {count} {count === 1 ? 'time' : 'times'}
</button>

这么几行代码就实现了一个点击 +1 的按钮，他背后做的编译工作就很多，最后输出的 JS 有大几十行，感兴趣的话可以去官网上看，他有前后的输出代码对比，https://www.svelte.cn/

不止哦，JS 现在流行搞各种编译，拿到 AST 之后做骚操作。比如 React：

function App() {
  return <h1>Hello World</h1>;
}

编译之后会变成

function App() {
  return React.createElement('h1', null, 'Hello world');
}

然后还有一个 build 的重点就是 TreeShaking，这个操作会把一些不用的东西丢掉。比如一个库有两个函数，你只用了一个，他会在编译的时候把你不用的函数、常量全都丢掉，不会放到最终输出的 JS 文件中。

Rails 这个 Promise 有 Promise.all 这种操作吗，看起来应用起来还有点难受

实在不行只能内部活水换个 base 去武汉了，但主要回家了不想再在大厂这么卷了

买不起房

对于公司来说确实是的，饿死了就什么都没了，干啥都得先考虑活下去

所以现在还有很多外包公司都还是 PHP 技术栈

如果是创业，其实没有任何技术有研究学习的价值，能把产品做出来、卖出去赚到钱才是唯一重要的

对比现在用的多的 Go 和 Java，Ruby 这个语言就天生效率高，但是如果团队太大，项目太膨胀，还是很蛋疼的，Go 和 Java 的优势就起来了

一旦有违法乱纪的组织用你的产品交流了什么事情……搞不好整个开发组都得蹲号子

这种产品在国内做，需要办很多手续吧

其实看源码最大的问题时，ts 总是会跳转 d.ts 声明，导致看不到代码实现，只能看到函数签名

所以大家都不想升级依赖，只要能跑就不动，嘿嘿。

正常流程：

1. 根据报错问 GPT
2. 根据报错搜 Google
3. 搜不到提 issue，但作者回不回复你看运气
4. 要么回滚，要么自己翻源码

本机用 rbenv 管理 ruby，RubyMine 开发，其他的数据库之类的要么 Docker、要么在服务器上远程连接

rails5 往后基本都是在前端上折腾了，不过我基本都用 api 模式了，不影响

1. 内部看看有没有大前端团队，回头活水过去做全栈，跟着业务做才能学到东西，自己整很难学出来，因为国内大厂业务压力太大了，你没多少时间做的
2. 一般全栈团队不是 node 就是 go，对后端来说语言、框架都不重要，学啥都无所谓，更重要的是整体的设计能力和经验

机器太老了，不应该升级新系统的，可以试着回滚一下 10 版本的系统

intj

很简单，你这里应该先在接口里校验好友关系，如果不是好友需要报错 403 forbidden 之类的。

接口不应该信任前端参数，必须做校验的，不做校验就是安全漏洞了。

做应用程序还是得先把产品搞明白，定位、受众、核心功能。然后进行数据建模，想想数据库需要哪些表、每个表要什么类型、彼此之间什么关系。最后后写接口、页面就好了。

看你怎么定义完美的应用程序，有的应用产品上大成功，代码可能和屎一样；有的产品代码异常精妙，就是没人用……

买了，但被公司屏蔽了 ，在公司用不了。

公司表面说是有代码泄露风险，但实际上感觉是想自己造轮子搞 KPI，自己搞了套类似的，我真吐了，还写对比表格：“性能和准确度不如 copilot 但是风险可控”。