前言

OneDrive 是微软公司提供的一项云存储服务。用户可以通过 Microsoft 账户注册 OneDrive 后获得一定量的免费存储空间，例如起初通常有 5GB 的免费存储空间。OneDrive 支持多种操作系统，包括 Windows、macOS、iOS、Android 等。用户可以在不同设备上同步文件，并能够通过设置共享链接与他人共享文件。

对我来说Onedrive是一个很不错的云同步工具，我日常用它来进行笔记数据的多端同步，然后搭配Obsidian这类Local First的笔记APP进行使用，就可以安心地在多端进行笔记同步（顺便完成数据的备份）。总得来说，5GB的免费空间对于笔记这类文档资源来说可以用好多年了，且Onedrive的文件同步真的很快速且安全，很少出现同步错误的情况。

Onedrive同样提供了API的方式让开发者去访问授权用户的存储空间，进行存储空间内文件的增删改查相关操作，以便开发集成Onedrive的应用。不过我这里主要是利用Onedrive的API去接入自动化服务，以便可以让自动化服务能够修改特定文件达到个人信息流入口聚合的功能。

虽说这里我使用Onedrive API的目的只是为了访问自身的存储空间，但实际上访问其它授权用户的存储空间也是一样的流程，没有区别。

前言

此文原为对公司内部某个 Vue2应用存在的严重性能问题，进行优化后笔者进行的内部总结文档。个人觉得其中一些分析思路和方法还是值得回味的，且暴露的一些引发性能问题的做法也值得吸取经验，故而现在进行对其中一些数据进行脱敏后进行发布。

某编辑页性能问题表现

• 当 tab菜单切换时会出现肉眼可见的卡顿
• 浏览器页面内存随着切换次数的增长而增长（经测试，最高可占用 3~4G的内存），直至页面崩溃

传统请求库的痛点

传统请求库（如 axios或浏览器的 fetch API）专注于请求本身，这一点上它们的职责其实很专注，在请求这一功能上已经做得挺不错了；不过实际业务和项目中跟请求相关的一些常用的功能，这种请求库通常不会提供，虽说我们可以根据自身业务需求自己抽象出一些常用的功能，形成自己的请求策略库或者类似的工具，但偷懒是人之本性🙈（其实也是为了避免重复造轮子）。

为什么要使用状态机？

如果一个交互只简单地涉及到布尔状态或者是多选一，这类只通过一个状态变量即可确认当前状态的场景确实没必要使用状态机，毕竟无非只是使用if/switch就能简单切换状态。如果一个交互逻辑复杂到需要使用多个状态变量来共同确认具体的状态节点，那么在涉及到状态切换时，对于判断当前具体状态节点的相关工作量就会呈现指数级的增长；

关于 ts-morph

ts-morph是一层对TS编译API的封装^[1]，使得操作AST变得简单高效起来，且提供了开箱即用的项目级编译支持，因而可以很快的构建自己的TS项目编译上下文；除此以外，ts-morph基本上保留了所有原始TS AST节点类型的访问，因此如果有啥TS编译API目前还没封装暴露，可以完全退回到原始API进行相应的使用^[2]，所以不必担心ts-morph会有过度封装而导致无法使用一些底层API。

关于 TS 编译 API

顾名思义，就是用于TS编译的，通常用于获取和编辑TS AST（抽象语法树）信息，直接通过typescript这个包提供；关于TS编译流程、AST数据结构以及常用的编译API就不再赘述，更多可以参考——TS AST转换实例：从类型声明生成初始化数据 | snowdream；

关于 AST

简言之，AST可以获取到源码的所有（合法）语法信息，同时构造（或修改）AST也能得到对应的代码，可以理解为AST结构与代码之间是一种双射关系。

AST的用处很多，常见的language server都会借助AST信息来进行各种语言DX功能开发（如：自动补全、类型显示、语法诊断、代码格式化等等）；同时，由于AST结构可以转换为代码，所以修改AST结构可以从语法层面进行代码的修改（这比直接从文本替换来说效率高多了），因此AST也被来扩展语法的使用（前提是合法的语法，即从一种合法的语法转为另一种合法的语法，以便提高开发效率）；

P.s：如果修改AST已经不能满足你的语法需求了，那么是时候考虑进入诸如TC39这种语言标准化组织或者开辟自己的语言了😁。