我之前开发需要与后端通信的 Chrome 插件也遇到类似的问题，我的解决办法是买的阿里云 99 一年云服务器，在应用里面写死 IP 实现的。

犀牛书给我的观感就是太厚了，很多内容也就是科普水平，不如《高级程序设计》信噪比高，Google 了下，新版厚度减少了许多，但内在还是一样，也就是读的时候要分清哪些是干货，哪些是水，对于 JS 新手而言是个问题。

前面的批评也不是没有道理，JS 并非轻量级 Java ，虽然 JS 受到了 Java 很大影响（或者说蹭热度），比如语法风格，比如基于 UTF16 的字符串类型，对写 Java 的人来说上手很快，但原型链就足以证明它不是 Java 。

JS 的生态位就不同于 Java ，何来“可惜错过了，地盘也抢不回来了”，你为 JS 搓手顿足、懊恼，有点表演型人格发作了。

从性能来讲，JIT 加持的 JS 程序在单线程接近甚至战平 JIT 加持的 Java ，内存占用两者都比较粗狂，但 Java 是支持多线程的。不考虑生态，单纯从性能和内存占用角度来讲，对于单线程程序，选择 JS/TS 和 Java 没太大区别。

细想一下，接口类型的约定是方法调用，而 null 值是可以作为方法接收者（需要调用方保证），因此接收方只需要检查是否提供了类型（即`==nil`判断）。

你唯一需要进一步检查值是否为 nil 的情况，是进行类型断言，断言成功的结果是一个确定的类型而非接口类型，此时你对断言结果进行`==nil`判断也不会存在什么问题。

所以这个设计看似不合理，但其实很合理，除了面试八股，或者研究茴香豆的写法，这个设计并不会导致写出 BUG 代码。

@CLMan 更正“也不是没有问题”为“也没有问题”

tour of go 和《 TGPL 》都应该重点讲过这个问题，但如果很少使用到接口，确实长期下来会遗忘这个问题，所以说是坑也不是没有问题。

至于为什么这么设计，虽然没去查权威来源，但个人的推测是，Go 中 null 是可以作为方法接收者的，所以需要区分带类型的值为 null ，与不带类型且值为 null 的情况。

Go 的 for i range array ，其中 i 是索引值，省略了值。这对于习惯了 JS 和 Java 语法的我，很久没写 Go 再回去写，也经常犯错误，在迭代整数 slice/数组时，把 i 当作元素。

最开始是用 npm ，属于入门阶段。然后尝试了 yarn ，它的特色是`Zero-installs`，但是个人项目用不到。最后尝试了 pnpm ，被它的执行速度和 0 学习成本（对于 npm 的兼容性很好）所吸引，就停在了 pnpm 。

最近尝试了 bun ，主要是用来当作 TS 的解释器来用，也用来写一些脚本类型的项目，因为它提供的 API 比 Node.js 的 API 更加友好，冷启动速度也更快。

测试过 bun 和 node.js 在 Linux 作为自己的一个后端 JS 程序的 Runtime ，两者(JIT 暖机后)性能、内存占用基本一致，没什么差距。

"更多优秀"，但是并没有指名道姓的说出来，太敷衍了。

因为 fetch 和 超链接跳转 是两种不同的跨源网络访问，对浏览器而言，会采取不同的跨源安全访问限制策略。前者由脚本触发，后者由用户点击跳转，所以浏览器对于前者会更严。

更细节的需要爬文档： https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS 。以及多做测试，CORS 涉及到安全，不同品牌的浏览器在一些细节上存在差异，需要自己整理。

我自己修过（指替换零件、毕竟修主板还是得专业人士）、清理过几个笔记本，倒是总结出一些经验。

相变片没用过，硅脂不是越厚越好，硅脂的作用在于填补铜片与 CPU/GPU 接触面的缝隙，你只需要表面保证完全覆盖薄薄的一层，拧紧螺丝就行了。

拧散热器螺丝要讲究技巧，按照 X 的交叉方式先拧几圈固定螺丝，然后循环这样的方式，直至把所有螺丝拧紧，这样是避免硅脂不均匀分布。

现代笔记本的散热模组都是一体化的，可能散热模组老化或者你清灰过程中造成了物理破坏，最好的方式是淘宝买 2 个新的，一个替换，一个备用。

拆机前最好看下视频和教程，避免遇到坑，别自己蛮干。

模式 1 ，定义了一堆 interface ，模块执行逻辑在 New 里面，间接在 run 里面。
模式 2 ，定义了一个通用的 Module 接口，模块实现 Module 接口，模块执行逻辑在 Run ，由 Manager 在 run 里面调用。
模式 3 ，定义了一个通用接口 Stage ，以及定义了一堆 interface ，模块实现 Stage 接口以及自身的接口，模块执行逻辑在 Run ，由 Manager 在 run 里面调用。

所以你这 3 种模式，无非就是抽取了一堆接口，有点 Java 了，代码的可读性没有任何区别。

首先，模式 1 的将模块执行触发丢在 New 里面，通常是不建议的，因为多模块系统是由模块组装得到的，最后再走启动的流程，模块提前执行是不合适的。

其次，除非真有必要，Go 是很少上来就抽取一堆 interface ，建议先写下原型，根据实际需要再抽取接口。

至少 Google 一下 Flutter 和 Dart 的历史吧。

是 Chrome 团队先发明了 Dart ，试图取代 JS 用于 Web 开发，但是由于市场接受度不高，因此暂时沉寂。

但是代码/编程语言对于 Google 来讲就是资产，只要有合适的场景就会翻出来拿来使用，毕竟都是真金白银换来的积累。

随后，Google 与 Oracle 陷入了关于 Andorid 使用 Java 的官司，Google 一方面和 Oracle 在法院扯皮，一方面在软件层面准备了 JB 的 Kotlin 和 Chrome 团队的 Flutter 方案，因为 Chrome 团队正好在 UI 上积累了很多经验，之前开发的 Dart 也很适合来干这件事情。

对于 Google 这种大公司，给自己操作系统(Android)编写 GUI ，其使用的语言必然是自己的，苹果为啥要发明 Swift ，微软为啥要发明 C#这个和 Java 同生态位（至少早期如此）的语言，因为自主才能掌控全局不然处处受制于人，不是很简单的道理。

"Python 初学者"，错，“编程初学者”，对。

其实你是基本对编程没有什么概念，因为对于有编程经验/思维的人来说，Python 入门也就一个下午的事情。因为你也不用来写什么复杂东西，Python 看个语法部分就算入门了。

用 math adventures 来入门是你想多了，里面的 Python 内容不成体系，里面的数学内容也不成体系，你不是数学专业出生的，哪来的背景知识看，看天书吗？

我读大学的时候，大一基础课之一就是 C 语言编程，这种教育依然是灌输式的教育，典中典的谭浩强 C89 ，坑害了多少人。不知道现在大学的培养方案变更没，这类课程的目的，其实就是要教会学生编程思维。

如果要推荐，CS61A 应该是合适的，包括视频，基于 Python ，讲解编程思维。

因为前面已经过滤 null 了，后续就不需要再检查 null ，所以你改得没啥问题。其次这代码本身就怪怪的，分页查询返回的 List 包括 null 元素（难道是返回固定长度的 List?）

感觉你应该没有太多编程经验，去看这种后台管理项目，去扣它的业务逻辑细节，实际上是走入了误区，想得太多写的太少。这种项目就是用来二次开发的，你自学根本没有实际的需求，看这种只有皮而无肉的空架子代码，那自然会陷入“这里要不要检查 null”，“这里为啥用 Throwable 而不是 Exception”等基本上没啥意义的实现细节。

我的看法是，真正能够有所收获，建立信心的是写自己的项目。你去找一个自己感兴趣且熟悉的领域，找到切入点，写一个至少能用的应用，不需要功能多丰富，实现多完美，至少其是自洽的，麻雀虽小，五脏俱全。比如你的求职目标是 Java 后端，那就去仿一个网站，从需求分析、数据库设计、后端实现、前端实现、应用部署一步步做起，并且去相关垂直领域宣传，给别人使用。

@xxss0903 你这涉及到字体等资源文件了，我只用 TypeScript 写过传统的逻辑库和 web 应用，没写过 web 组件库。

你可以参考与你项目类似的 pdf.js： https://www.npmjs.com/package/pdfjs-dist ，看它是怎么打包资源文件的。

当代软件开发都是需要包管理器的，学习包管理器就和学习编程语言一样，概念都是一通百通。npm 学习成本并不高，只不过在国内需要配置代理这项额外学习成本，建议用 pnpm 。

@CLMan 之前没看你项目源码，看了下，引入 vite-plugin-dts 是正确答案。

vite 是开发 web 应用的脚手架，你只是开发模块/库，如果不需要使用 web 页面进行辅助开发和测试，是不需要上 vite 的。

当然上了也不是什么错，毕竟可以利用其默认配置，比如 eslint 、prettier 相关默认设置。但是需要额外的配置，因为 vite 是面向 web 应用设计的，你用来开发库，其构建目标就和默认情况发生偏差，你需要添加额外的构建配置。

前面楼层提到的 package.json 里面的`exports`,`import`,`types`等字段，应该由构建工具来修改，不建议手动修改。

ESM 现在是主流的模块解决方案，webpack 这样的旧时代构建工具很少被使用了，构建工具有 rollup ，也包括前面提到的 tsup ，vite 是基于 rollup 的，所以你没必要引入额外的构建工具，当然你硬要用 tsup 也不会存在什么问题，只是 rollup 与 vite 集成度更高而已。

如过你使用 rollup ，就需要添加 rollup 的相关配置来构件库。你需要阅读 rollup 官网文档，以及 vite 官网的 rollup 部分的文档，了解如何添加构建库的配置。

这就是你这问题的相关解决思路。

个人只对桌面 GUI 跨平台有些了解。

wails 和 tauri 都是基于桌面系统自带的 webview ，优点是不需要像 electron 那样每个应用带一个运行时，但较老的 Windows 系统，得自带运行时的安装包或者下载器，或者让用户手动安装运行时。webview 的缺点就是性能较差，首屏加载有 0.5s~1s 的延迟。

如果对桌面 GUI 的性能有追求，那用 flutter 不错，磁盘占用、内存占用、性能都很优秀。

Compose Multiplatform 本质上就是 Java GUI ，试用过两个基于其开发的产品，内存占用和磁盘占用表现较差。

用过第一代 surface pro ，后来当泡面盖子了，对我个人而言没啥用。触控笔对于写程序的用处不大，其实际体验对于使用者的手写能力要求较高（比如专业绘画等），对个人而言不如键盘打字。

个人还是习惯传统笔记本，追求键盘手感。