起因（源自一个现实的需求）最近公司有一个大屏开发的需求，其中的布局要求需要做到自适应。我的想法是通过 css flex 布局进行实现。（当然，简单点可以用 px2vw 的方案去写设计稿的参数，但是要考虑到尽可能的完美适配，可能会有像素误差，我就不使用该方案去实现。） 需求如下： 有一个父容器撑高至最大的高度。 父容器内有一个子容器也要撑到最高，且它的内容要做到溢出滚动的效果。 大概的设计稿如下： 实际代码和理想的情况不一样这是我自己实现的代码。（样式代码通过 tailwindCSS 实现） 因为层次很多，这里我是通过 flex-grow: 1 的方式将容器撑满。 <div class="flex flex-col w-[100vw] h-[100vh]"> <!-- 父容器 --> <div class="flex flex-col flex-grow-[1] p-[20px] border-solid border-[1px] border-[brown]" > <!--

为什么要学习 TypeScript ？ 动机 在常规的 JS 项目开发中，尤其是大型项目里，我们没有办法时刻知道当前对象会拥有什么属性，就会导致心理上产生一种负担。即当我们用键盘按下访问符 ‘.’ 时不清楚该选什么属性or方法。TypeScript 的出现正式减少我们心理上的负担。 类型检查，ECMA协会发布的常见 JS 异常是类型异常，由于 JS 是弱类型不具备类型检查的能力，需要在运行时才能发现问题。所以 TS 能在编码阶段就可以定位出大部分类型异常的问题。 能解决什么问题？除了上述的问题，良好的 TS 的类型编写可以成为项目的文档，让后续的维护成本降低（但不要忘了前期的 类型编写 也是需要时间的）。编程上的约束 新手学习路线学完即可直接上手做项目 搭建一个适合自己的学习环境 tsc（TypeScript Compiler）将 ts 代码直接编译成 js 代码。（不太适合学习时使用，执行编译后还需要手动执行一次运行，不方便） ts-node（推荐）是一个 CLI 工具，它可以直接运行 TypeScript 代码，无需先编译成 JavaScript。这对于开发和调试非常有用，因

开头这一年过得和这个标题一样，非常得干净、普通、没有半点色彩。当然这篇总结也是非常的言简意赅。 回忆 今年的我异常地喜欢稳定的感觉，所以我一直在寻找这份所谓的稳定感，为此我也承担了一定的代价，但到了最后我彷佛被反噬了一般不得所愿，上帝彷佛在告诉我 go fuck yourself! 可能是我运气太背了吧，从结果来看（虽然这么说不太好）我总是做错选择，才导致自己被反噬而陷入了痛苦之中。为此我也在思考这是我所想要的吗？我需要再改变现状吗？ 一些新的尝试，去旅游、听演唱会、尝试思考一些新的自己从未思考过的问题。想出去看看世界的样子，与其听别人说不如相信自己所见的。 学会精打细算。当我在寻求稳定感的时候，我也承担了相应的代价，为此我需要压缩我的生活成本才能让我好进行良好的储蓄。为了省钱，我还是得做出一些妥协，衣食住行和娱乐都进行适当的削减。不过这让我看来反而也是一种进步吧，把以前的铺张浪费的坏习惯去掉也算是本年度为数不多值得庆幸的事情了。 关于学习。我还是挺看好区块链相关的技术，尝试自己学习 Web3 相关的知识，然后自己跟着写写合约和钱包的项目。关于 TypeScript 方面，我也自

这篇是在什么情境下写的？出来工作的第五个年头，大公司、小公司都呆过，各种东西都在变，维度是后端的 API 永恒不变 ———— 一直都很随便。每逢有一点风吹草动（项目需求变动大），你都得重新修改被引用接口部分的代码，如果碰上了一个文件上千行代码就真的很头疼（加油）。如果还碰上 解构+别名 就更痛苦了。 我每每遇上这些问题，我都会想去写下这篇文章，但每次下笔前我都会想：会不会是我太菜了，明明改个代码就好了，是自己的阅读代码能力太弱了。但自从我的道德素质下降了之后，这 TMD 都是后端的问题，不接受任何反驳！ 我最新的理解是：前后端的联动基本都在 API 的层次上，其实我们不应该太过关注后端返回的数据模型的 类型、结构 。（前提是满足当前业务需求），而前端应该以 AOP（类似 graphQL） 的方式去处理它，在其它相关的业务代码里不应关心它，或者说不值得为了这接口写一大堆辅助方法去尝试调整成所需要的模型结构。这些统统都在 DTO 文件里实现，这让业务代码变得清爽不少。 以前学过 Java 和 Spring ，里面的 Java Bean + 注解 可以提高生产力，然后还有 DTO 的概念，正

序言Vue2 的项目写了几年，基本都是使用 js 的方式去书写。我发现随着项目的壮大这其中会有很多问题影响着项目的后续开发和维护，比如：文件的跳转文件（组件间）的关系难以一次性的理清，尤其是新人进入的项目，如果通过当前的代码在一个庞大的项目里去翻找特定的文件，想必是很痛苦的（查找引用关系，还有概率遇到重名的文件需要自行辨别），但由于现在的 sfc 文件和 VSCode 的 vetur 插件并不是很完美做到文件跳转。如果此时能做到一键跳转，岂不是减少不必要的查找时间，又能理清楚文件（组件）间的关系，减少许多心智成本。 类型提示虽然现在 Vetur 和 Volar 这两款 VSCode 插件已经能做到简单的 props 和 event 的提示（这需要一定的前提，比如：jsconfig 或 tsconfig 做好路径别名的配置），但是遇到 attributes 和 event 的透传还是有心无力的。提示依然会有不准确的情况。（即：any） 最后，我发现使用 TS 的方式去编写项目可以完美的避免以上的问题。到现在 2023 年，vue2、3 都已经完全支持 TS，类型提示妥妥的没问题，然后 V

前端测试的作用与价值一句话总结测试的重要性：如果你需要快速的去修改某段陈年代码又不清楚改完后有没有其它副作用，一个详细的测试代码就能帮助你，给予你信心和安全感去改动这段代码。 测试的价值：尽可能减少修改代码所带来的未知问题，在项目上线前就扼杀掉。 测试的种类有几种？ unit test特指： 公共函数/组件 这一类低耦合的代码。 通常情况下，在公共函数/组件中一定要有单元测试来保证代码能够正常工作。单元测试也应该是项目中数量最多、覆盖率最高的。 评价：我认为单元测试应该是项目的主流，因为他的投入成本较低，回报率相对业务代码高，因为 公共函数/组件 使用率高。 intergration test特指： 耦合度较高的函数/组件、经过二次封装的函数/组件、多个函数/组件组合而成的函数/组件 的代码。 评价：虽然集成测试是安全感较高的测试，能很大程度提升开发者的信心，集成测试用例设计合理且测试都通过能够很大程度保证产品符合预期。但是成本和回报率相对于单测要低。因为需求的频繁变化会导致测试代码的编写变得无用，所以集成测试也不太适合在国内公司落地。 UI test特指： 类似于用 pupp

核心原理MicroApp 的核心功能在 CustomElement 基础上进行构建，CustomElement 用于创建自定义标签，并提供了元素的渲染、卸载、属性修改等钩子函数，我们通过钩子函数获知微应用的渲染时机，并将自定义标签作为容器，微应用的所有元素和样式作用域都无法逃离容器边界，从而形成一个封闭的环境。 实践创建 基座应用 与 子应用 micro-app 不推荐使用 vite 项目作为 子应用，所以 vite + vue3 的用户会很很亏，只能通过 vue-cli 的形式去创建 vue3 项目。也可以使用 vite ，但是需要手动把沙箱功能关闭，因为不支持 vite 的 module script 基座应用不需要考虑用的什么技术，主要考虑在子应用。 子应用记得把 CORS 规则放开。因为 micro-app 是通过访问 url 的形式去获取资源的。 // vue.config.js module.exports = { devServer: { headers: { "Access-Control-Allow-Origin":

pnpm 的介绍引用官方的话： 节约磁盘空间并提升安装速度 关键技术点软硬链接pnpm 的高效来自于硬链接，是指：新建的文件是已经存在的文件的一个别名，当原文件删除时，新建的文件仍然可以使用，只当所有文件都删除了，才算是真正的删除。 软链接：也称为符号链接，新建的文件以“路径”的形式来表示另一个文件，和 Windows 的快捷方式十分相似，新建的软链接可以指向不存在的文件.（或者是 npm link 通过一个符号，比如：vue 然后执行一个映射仓库的脚本 vue script 类似执行某个脚本） 引用自：https://www.cnblogs.com/itech/archive/2009/04/10/1433052.html 与 monorepo 的配合monorepo 与 multirepo 的优缺点pnpm 的 monorepo 在 CI/CD 的优点，不用频繁的切换目录就可以使用特定包专属的命令 pnpm -F 可以直接在根目录就实现调用任意命令。 monorepo 的优点： 统一工作流由于所有的项目放在一个仓库当中，复用起来非常方便，如果有依赖的代码变动，那么用到这个依赖的项

1，Vuex 中的 state 不要用 = 赋值一个对象。 这样，这个对象的属性就不具备响应式了。例如：在 computed 里都不能监测数据的变化了。 且尽量写好默认值，让后通过 Object.assign() 进行逐一赋值。 2，获取 userinfo 的接口在调取后，应该持久化在本地。 妈的，每次刷新页面都要重新获取 userinfo ，然后就会不断重现 1 的问题。建议用 vuex 时，配合 vuex-persistedstate 3，要善于用页面守卫，不要一股脑的用全局路由守卫。 老把针对某个页面的路由业务写在公共的路由守卫上真的好？代码一多起来，不就难受死你？ 4，关于退出登录 以免有什么坑爹的参数忘了没有初始化，就老老实实原地刷新一下界面吧。 5，开发的path应该和生产环境的path都对应上，不然调试会变得麻烦。 比如我们生产环境用的是 https://domain.com/page/xxx.html#/xxx 这个路径 本地开发用的就是 http://localhost:8080/page/xxx.html#/xxxx 这个路径。 举个例子：如果我们开发多页应用，某个

0，设置远程仓库的 urlgit remote set-url origin <远程仓库的 url> 如果提示 No such remote ‘origin’ 则说明需要你添加一个远端名称（比如：origin） git remote add origin <远程仓库的 url> origin => 其实是别名（可以任意一个名字，这里只是跟随大流），代表你的远端仓库的名称。 啥是主机名？（不完全正确） 一般来说 origin 指的是你 clone 仓库到你本地时的一个别名。 如果你想推送到别人的仓库，就要添加一个新的主机别名才行。所以 origin 的用途就是这样了。 可以通过 git remote -v 查看主机名对应的 url 其中一个是 fetch 用的，还有一个是 upsteam 供 push 用的。 1，拉取远端分支到本地首先你需要先把远端分支下载本地上 git fetch（简写：更新所有分支） 或 git fetch origin （看看是否有人新加了分支） 再查看目前仓库所有的分支 git branch -a 再执行以下命令即可将远程分支co