@vicalloy 是的，就算膨胀后，也还是会比更小。

我的资源是 27 个 PNG 文件，在 PS 里直出，总共 104,325 字节。尝试用 ZIP 压缩，以失败告终。

写了一点打包代码，把 27 个 PNG 打包成一个 JS 文件，体积为 139,647 字节。

这时候用 zip 再次压缩，最终大小为 88,165 字节。

@LeeReamond "其他的所有 js/css/图片全都是 0ms 内存缓存，感觉就是开启成功了啊"

正常 http 缓存，也是先内存加载的。内存没有才找磁盘加载。

至于过期时间，一般资源设置的时间，还是挺长的。

在我眼里就是一个 http 代理。

大网站不用的原因，就是不想让你离线用吧。

我工具网站没用，是因为 HTML 页面频繁更新，每次都希望向服务器检测一下，看有没有最新数据。

只要不下载资源，返回 304 速度很快的，和 service worker 离线几乎没多大差别了。

JPEG 编码需要转换到频域操作，完全没学过，从头开始还是挺繁琐的，概念和细节很多。

你不如和导师建议，把 JPEG 改成 PNG 编码器，反正都是邻居。

PNG 也就是 Huffman 套个马甲，那个简单多了。

哈哈，这脑洞够大，也是闲人一个。

K 线是一维的，解释不了宏观和微观，我就用二维图片来代替。

一张堆满细节的超高清图片，在普通的 1080p 显示器上全图显示，细节是自动被抹去的，所谓的下采样。

细节一直存在，但是你看不见，你也不在乎，代码缩放也是这个道理。

放到最大，函数能看见。缩到全图，就自动退化成一个点了。这时候所谓函数名，函数参数都都不重要，用指令包裹起来，我只要发布指令和命令，软件能正常运作，就足够了。

@FrankHB 我们说的都不是一回事，你是说哪一种代码实现方法更好，可我说的是整体设计方向。

一个是低维，一个是高维，两者没办法放一起对比的。

你细节 API 代码只要花时间，最后怎么都能写好。但是管理海量代码，是需要一点技巧和模式的。

@liuhan907 "为什么你会认为指令比函数更容易维护？"

你要管理一整套基于函数的语法树，构建 AST 是相对复杂的。而程序化去提取指令，要简单太多。

你可能没接触过项目遗留屎山，就是函数和代码量多到，你怎么都改不过来。有时候并不是谁好谁坏的问题，是你看问题的角度不同，舍取的问题。

宏观对我来说，就是把函数细节抹掉，把精力省下来，留到更有意义的事情上。

@liuhan907 "何况大规模下几万个指令和几万个函数的理解成本没有什么区别。"

设计指令的目的，都是为了在不同维度下，让开发体验保证一致。

拿股票 K 线举例，你短线操作会观测到的细节，对于长线波段是没什么价值的，把细节抹去或者隐藏，才能让你更专注到更大的盘面，始终保持掌控力。

你封装函数，封装对象，同样也是为了隐藏细节。这帖子就是为了讨论宏观把控力，协程这些真的都是很枝末细节的部分。

海量函数能不能被很好的管理，要看开发者的经验。但指令模式，一定是可以用代码方式，科学维护管理的。

@Macolor21 以上古的 win32 编程举例吧。

一个 message ，就是一个 WM_USERREG 注册函数，加两个未命名的 wParam 和 lParam 。

没有函数体，不用给函数起名字。只需要 WM_USERREG 和若干个未命名参数，就可以执行一段用户注册的逻辑代码，并顺利返回结果。

反正就是这个意思。

@liuhan907 "你认为的指令和函数本质上的区别是什么 再增加一层抽象得到了什么好处呢？"

好处就是宏观写法和微观写法隔离开。

你管理几百个函数也许没问题，在几千上万个函数里跳来跳去，还是很有压力的。

我自己建立了一套指令网状体系，可以很快跳到自己需要修改业务的位置。

比如 Restful 的注册函数，正常写法，可能用户注册就是对应一个注册函数。

而我就是一个 RPC 的注册指令，和外部路由绑定后，就直接处理了。

@liuhan907 我这里的指令类似于 LUA 脚本定义，每个指令都是负责控制一堆函数体。是函数集的上层抽象。

函数里我一般不习惯牵涉业务，业务太多太杂，命名太辛苦，写一大堆函数没多大必要。而指令大部分都是能和业务实际挂钩的。

可能没代码很难理解，指令可以看成是 onmessage 里的一个个接受命令体，没有自己的函数入口，但能正常调用别的函数。但很可惜那个详细说明的帖子，我自己也找不回了。

我以前发了一个去函数编程的方案。

也就是用命令式指令，去替代传统函数的封装。类似一点 DSL 的定义。

可惜最后被移到了水深火热专区，因为大家都不信，去了函数后还怎么写代码。

这就是大家编程理念不同，微观上是函数，宏观上就自然升级到了指令。真是残念，我好多贴都去了水区，一去不复返。

"3.国内做这方面的开发是否需要承担法律风险？"

说出来可能有点尴尬，国外合法的高频交易，到国内就变成了异常交易和市场操纵( https://zh.wikipedia.org/wiki/高频交易)

设计软件就炒股一样。股票里 K 线图有个著名的随机游走策略，导致你不管做短线，中线，还是长线，输赢概率是相同的。微观操盘和宏观操盘上，体验是一致的。

套用在软件开发也类似，从微观设计 API ，和宏观调用 API ，也需要保证开发体验是一致的，才能控制好全局。

不能因为代码增多，就陷入局部细节。要不断的封装对象，隐藏细节，让代码流程保持在一定可供总量。往往代码量太多，又没有合理的封装，才是屎山的开端。

至于“函数式编程的优势”，个人觉得就是能做到无状态编程，没内部状态维护，那么固定输入后，输出结果都是可预测的。能减少一些心智负担。

@dfkjgklfdjg “如果我上边说的 3 点都不能满足，或者说连起码的社保福利也不能满足你，那么你就得考虑问什么自己会出现这样的问题，只能选择这样的公司。”

有头部就有尾部，很多人就是一个很平凡的普通人，没想那么清晰的职业规划，就希望找个好公司，不加班，轻轻松松写点代码。

但这愿望放在一线大城市，是很难实现的，就因为行业很卷。理工科有能力的人并不少见，是真的要比隔壁文科卷的多。

如果有实力榜身，找工作也不迷茫。可迷茫又没实力的年轻人，才是主流和常态。

@stoneabc

所有的定义和使用场景，都是人为给予的。

对于计算机来说，就是 0 和 1 ，图片处理是定长压缩算法，还是变长压缩算法。

又或者是不是频域处理，一点都不重要。重要的是，ASTC 能很好的压图片，至少比 PNG 要好吧。

@Cmtter “这个模型怎么同时让全世界的设备（从手机，电脑，服务器到那些裸机设备）都能接受和支持并高效的跑起来是个很大的问题”

WASM 是万能的，速度也足够快了。