用proxy实现一个更优雅的vue 前言如果你有读过Vue的源码，或者有了解过Vue的响应原理，那么你一定知道Object.defineProperty(),那么你也应该知道，Vue 2.x里，是通过 递归 + 遍历 data对象来实现对数据的监控的，你可能还会知道，我们使用的时候，直接通过数组的下标给数组设置值，不能实时响应，是因为Object.defineProperty()无法监控到数组下标的变化，而我们平常所用的数组方法 push, pop, shift, unshift, splice, sort, reverse,其实不是真正的数组方法，而是被修改过的,这些都是因为 Object.defineProperty() 提供的能力有限，无法做到完美。网上看过很多关于Vue的源码解读或者实现一个简易版的Vue的教程，还都是用 Object.defineProperty (大概是为兼容性考虑吧),而 Object.defineProperty() 确实存在诸多限制, 据说Vue的3.x版本会改用Proxy，那么今天我们就先来尝尝鲜，用Proxy实现一个简单版的Vueproxy 介绍Proxy 用于修改某些操作的默认行为，等同于在语言层面做出修改，所以属于一种“元编程”（meta programming），即对编程语言进行编程。Proxy 可以理解成，在目标对象之前架设一层“拦截”，外界对该对象的访问，都必须先通过这层拦截，因此提供了一种机制，可以对外界的访问进行过滤和改写。Proxy 这个词的原意是代理，用在这里表示由它来“代理”某些操作，可以译为“代理器”。以上引用内容来自阮一峰的es6教程的Proxy章节 原文地址请戳这里。我们来看看如何用Proxy去定义一个监听数据的函数定义 observe 体验AI代码助手 代码解读复制代码 _observe (data){var that = this // 把代理器返回的对象存到 this.$data 里面 this.$data = new Proxy(data, { set(target,key,value){ // 利用 Reflect 还原默认的赋值操作 let res = Reflect.set(target,key,value) // 这行就是监控代码了 that.handles[key].map(item => {item.update()}) return res } })}当触发set的时候，就会执行 that.handles[key].map(item => {item.update()}) ，这句代码的作用就是执行 该属性名下的所有 "监视器"那么，监视器怎么来的呢？ 请继续看以下代码定义 compile 体验AI代码助手 代码解读复制代码 _compile (root){ const nodes = Array.prototype.slice.call(root.children) let data = this.$data nodes.map(node => { // 如果不是末尾节点，就递归 if(node.children.length > 0) this._complie(node) // 处理 v-bind 指令 if(node.hasAttribute('v-bind')) { let key = node.getAttribute('v-bind') this._pushWatcher(new Watcher(node,'innerHTML',data,key)) } // 处理 v-model 指令 if(node.hasAttribute('v-model')) { let key = node.getAttribute('v-model') this._pushWatcher(new Watcher(node,'value',data,key)) node.addEventListener('input',() => {data[key] = node.value}) } // 处理 v-click 指令 if(node.hasAttribute('v-click')) { let methodName = node.getAttribute('v-click') let mothod = this.$methods[methodName].bind(data) node.addEventListener('click',mothod) } }) }上面这段代码，看起来很长，可是实际上，只做了意见很简单的事情，就是 "编译" html 模板，把有 v-bind、v-model、v-click 都给加上对应的 通知 和 监控通知 就是 this._pushWatcher(...) , 相当于是安装一个监听器，这样只要 this.$data 有发生 set 操作的话，就会执行this._pushWatcher 括号里面传的函数，来通知节点更新数据监控 就是 node.addEventListener(...) 监听相应的事件，然后执行对应的 watcher 或者 methodsthis._pushWatcher 又做了什么呢？ 体验AI代码助手 代码解读复制代码 _pushWatcher (watcher) { if (!this._binding[watcher.key]) this._binding[watcher.key] = [] this._binding[watcher.key].push(watcher) }这个就更简单了，如果 this._binding[watcher.key] 为空，就初始化，然后向里面添加一个 监听器最后，我们再来看看，监听器是怎么实现的定义 Watcher 体验AI代码助手 代码解读复制代码 class Watcher { constructor (node,attr,data,key) { this.node = node this.attr = attr this.data = data this.key = key } update () { this.node[this.attr] = this.data[this.key] }}Watcher 是一个类，只有一个方法，就是更新数据，怎么知道要更新哪个节点，更新为什么数据呢？在实例化（new）的时候，传的参数就是定义这些的这样，我们就实现初步的双向绑定了，整个代码大概只有50行。其实还可以更少，但是更少的话，就是继续阉割功能了(虽然目前实现的也是严重阉割版的)，但是我觉得实现这些，刚好可以不多不少帮我我们理解vue的本质。最后本文最终实现代码已经放在 github上，想要直接看效果的同学，可以上去直接copy，运行。如果觉得本文对您有用，请给本文的github加个star,万分感谢另外，github上还有其他一些关于前端的教程和组件，有兴趣的童鞋可以看看，你们的支持就是我最大的动力。作者：noahlam链接：https://juejin.cn/post/6844903621168283655来源：稀土掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

Vue实现组件 信息 的缓存 Vue实现组件 信息 的缓存当我们在开发vue的项目过程中，避免不了在路由切换到其他component再返回后该组件数据会重新加载，处理这种情况我们就需要用到keep-alive来缓存vue的组件信息，使其不再重新加载。在app.vue里<router-view></router-view>123但是这种情况会对所有的组件进行缓存，不能达到单个组件缓存的效果。那么我们给部分组件加上，实现方法如下：在app.vue里<router-view v-if="$route.meta.keepAlive"></router-view>12345678然后在设置路由信息的时候这样{ path: '', name: '', component: , meta: {keepAlive: true} // 这个是需要keepalive的},{ path: '', name: '', component: , meta: {keepAlive: false} // 这是不会被keepalive的}123456789101112这就实现部分组件缓存的功能如果缓存的组件想要清空数据或者执行初始化方法，在加载组件的时候调用activated钩子函数，如下：activated: function () {this.data = '';}123

一文看懂npm、yarn、pnpm之间的区别 本文作者对比了当前主流的包管理工具 npm 、yarn、pnpm之间的区别，并提出了合适的使用建议，以下为译文：NPMnpm是 Node .js能够如此成功的主要原因之一。npm团队做了很多的工作，以确保npm保持向后兼容，并在不同的环境中保持一致。npm是围绕着语义版本控制（semver）的思想而设计的，下面是从他们的网站摘抄过来的：给定一个版本号：主版本号.次版本号.补丁版本号， 以下这三种情况需要增加相应的版本号:主版本号： 当API发生改变，并与之前的版本不兼容的时候次版本号： 当增加了功能，但是向后兼容的时候补丁版本号： 当做了向后兼容的缺陷修复的时候npm使用一个名为package.json的文件，用户可以通过npm install --save命令把项目里所有的依赖项保存在这个文件里。例如，运行npm install --save lodash会将以下几行添加到package.json文件中。"dependencies": {"lodash": "^4.17.4"}123请注意，在版本号lodash之前有个^字符。这个字符告诉npm，安装主版本等于4的任意一个版本即可。所以如果我现在运行npm进行安装，npm将安装lodash的主版本为4的最新版，可能是 lodash@4.25.5（@是npm约定用来确定包名的指定版本的）。你可以在此处查看所有支持的字符：https://docs.npmjs.com/misc/semver。理论上，次版本号的变化并不会影响向后兼容性。因此，安装最新版的依赖库应该是能正常工作的，而且能引入自4.17.4版本以后的重要错误和安全方面的修复。但是，另一方面，即使不同的开发人员使用了相同的package.json文件，在他们自己的机器上也可能会安装同一个库的不同种版本，这样就会存在潜在的难以调试的错误和“在我的电脑上…”的情形。大多数npm库都严重依赖于其他npm库，这会导致嵌套依赖关系，并增加无法匹配相应版本的几率。虽然可以通过npm config set save-exact true命令关闭在版本号前面使用^的默认行为，但这个只会影响顶级依赖关系。由于每个依赖的库都有自己的package.json文件，而在它们自己的依赖关系前面可能会有^符号，所以无法通过package.json文件为嵌套依赖的内容提供保证。为了 解决 这个问题，npm提供了shrinkwrap命令。此命令将生成一个npm-shrinkwrap.json文件，为所有库和所有嵌套依赖的库记录确切的版本。然而，即使存在npm-shrinkwrap.json这个文件，npm也只会锁定库的版本，而不是库的内容。即便npm现在也能阻止用户多次重复发布库的同一版本，但是npm管理员仍然具有强制更新某些库的权力。这是引用自shrinkwrap文档的内容：如果你希望锁定包中的特定字节，比如是为了保证能正确地重新部署或构建，那么你应该在源代码控制中检查依赖关系，或者采取一些其他的机制来校验内容，而不是靠校验版本。npm 2会安装每一个包所依赖的所有依赖项。如果我们有这么一个项目，它依赖项目A，项目A依赖项目B，项目B依赖项目C，那么依赖树将如下所示：node_modulespackage-A-- node_modules--- package-B----- node_modules------ package-C-------- some-really-really-really-long-file-name-in-package-c.js1234567这个结构可能会很长。这对于基于Unix的操作 系统 来说只不过是一个小烦恼，但对于Windows来说却是个破坏性的东西，因为有很多程序无法处理超过260个字符的文件路径名。npm 3采用了扁平依赖关系树来解决这个问题，所以我们的3个项目结构现在看起来如下所示：node_modulespackage-Apackage-Bpackage-C-- some-file-name-in-package-c.js12345这样，一个原来很长的文件路径名就从./node_modules/package-A/node_modules/package-B/node-modules/some-file-name-in-package-c.js变成了/node_modules/some-file-name-in-package-c.js。你可以在这里阅读到更多有关NPM 3依赖解析的工作原理。这种方法的缺点是，npm必须首先遍历所有的项目依赖关系，然后再决定如何生成扁平的node_modules目录结构。npm必须为所有使用到的模块构建一个完整的依赖关系树，这是一个耗时的操作，是npm安装速度慢的一个很重要的原因。由于我没有详细了解npm的变化，所以我想当然的以为每次运行npm install命令时，NPM都得从互联网上下载所有内容。但是，我错了，npm是有本地缓存的，它保存了已经下载的每个版本的压缩包。本地缓存的内容可以通过npm cache ls命令进行查看。本地缓存的设计有助于减少安装时间。总而言之，npm是一个成熟、稳定、并且有趣的包管理器。YarnYarn发布于2016年10月，并在Github上迅速拥有了2.4万个Star。而npm只有1.2万个Star。这个项目由一些高级开发人员维护，包括了Sebastian McKenzie（Babel.js）和Yehuda Katz（Ember.js、Rust、Bundler等）。从我搜集到的情况来看，Yarn一开始的主要目标是解决上一节中描述的由于语义版本控制而导致的npm安装的不确定性问题。虽然可以使用npm shrinkwrap来实现可预测的依赖关系树，但它并不是默认选项，而是取决于所有的开发人员知道并且启用这个选项。Yarn采取了不同的做法。每个yarn安装都会生成一个类似于npm-shrinkwrap.json的yarn.lock文件，而且它是默认创建的。除了常规信息之外，yarn.lock文件还包含要安装的内容的校验和，以确保使用的库的版本相同。由于yarn是崭新的经过重新设计的npm客户端，它能让开发人员并行化处理所有必须的操作，并添加了一些其他改进，这使得运行速度得到了显著的提升，整个安装时间也变得更少。我估计，速度提升是yarn受欢迎的主要原因。像npm一样，yarn使用本地缓存。与npm不同的是，yarn无需互联网连接就能安装本地缓存的依赖项，它提供了离线模式。这个功能在2012年的npm项目中就被提出来过，但一直没有实现。yarn还提供了一些其他改进，例如，它允许合并项目中使用到的所有的包的许可证，这一点让人很高兴。一个有趣的事情是，yarn文档的态度开始针对npm发生改变，因为yarn项目变得流行起来。最开始的yarn公告是这么介绍yarn的安装的：*最简单的入门方法是运行：npm install -g yarnyarn*现在的yarn安装页面是这么说的：注意：通常情况下不建议通过npm进行安装。npm安装是非确定性的，程序包没有签名，并且npm除了做了基本的SHA1哈希之外不执行任何完整性检查，这给安装系统程序带来了安全风险。基于这些原因，强烈建议你通过最适合于你的操作系统的安装方法来安装yarn。以这种速度发展下去的话，如果yarn要宣布他们自己的registry，让开发者慢慢淘汰npm的话，我们一点都不会感到惊讶。看起来似乎要感谢yarn，npm终于意识到他们需要更加关注一些大家强烈要求的问题了。当我在审核我之前提到的强烈要求的“离线”功能时，我注意到这个需求正在被积极地修复之中。pnpm正如我所提到的，在pnpm的作者Zoltan Kochan发表了“为什么要用pnpm？”之后，我才知道pnpm。我不会介绍太多的细节（因为这篇文章已经发布很久了），但是你可以查看我的最初的帖子来寻找更多的内容，同时在Twitter上加入讨论。但是我想指出的是，pnpm运行起来非常的快，甚至超过了npm和yarn。为什么这么快呢？ 因为它采用了一种巧妙的方法，利用硬链接和符号链接来避免复制所有本地缓存源文件，这是yarn的最大的性能弱点之一。使用链接并不容易，会带来一堆问题需要考虑。正如Sebastian在Twitter上指出的那样，他最初是打算在yarn中使用符号链接的，但是由于其他一些原因放弃了它。同时，正如在Github上拥有2000多个Star那样，pnpm能够为许多人所用。此外，截至2017年3月，它继承了yarn的所有优点，包括离线模式和确定性安装。总结我认为yarn和pnpm的开发人员做了一个惊人的工作。我个人喜欢的是确定性安装，因为我喜欢控制，我不喜欢惊喜。无论这场竞争的结果是什么，我很感谢yarn在npm的脚下点了一把火，提供了另外一个选择。我确信yarn是一个更安全的选择，但是pnpm可能是一些测试用例的更好的选择。例如，它可以在运行大量集成测试并希望尽可能快地安装依赖关系的中小型团队中发挥作用。最后，我认为，npm仍然提供了一个非常有用的解决方案，支持大量的测试用例。大多数开发人员使用原始npm客户端仍然可以做得很好。

微服务架构设计 前言本文深入探讨微服务架构的优缺点及其核心设计重点。微服务通过将系统拆分为独立服务，实现了高可用性、可扩展性与业务隔离，但也带来了复杂度提升、基础设施成本激增及网络通信延迟等问题。适合正在评估或已采用微服务架构的软件架构师、开发者及运维工程师阅读，帮助读者理性选择技术方案并规避常见陷阱。目录 前言 1. 架构优点 1.1 高可用 1.2 可扩展性 1.3 内部业务逻辑相互独立 2. 架构缺点 2.1 复杂度高 2.2 基础设施成本呈指数增长 2.3 性能下降 3. 设计重点 总结架构优点1.1 高可用故障会被隔离在单个服务中。故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。┌───────────┐ ┌───────────┐ ┌───────────┐│ Service A │ │ Service B │ │ Service C ││ (独立) │ │ (独立) │ │ (独立) │└───────────┘ └───────────┘ └───────────┘ │ │ │ └────────────────┴────────────────┘ (隔离失败影响)1.2.3.4.5.6.7.1.2 可扩展性每个服务可以根据实际需求独立进行扩展。┌───────────┐ ┌───────────┐ ┌───────────┐│ 扩展方向 │ │ 扩展方向 │ │ 扩展方向 ││ → → → → │ │ → → → → │ │ → → → → │└───────────┘ └───────────┘ └───────────┘1.2.3.4.1.3 内部业务逻辑相互独立用特定技术把 income 请求根据不同的维度划分好独立的线程池，不要相互影响；由本服务发起的到其他服务的请求调用，也需要单独的线程池来处理。总之目标就是都独立，不互相影响，即便其他服务慢了，自己也不慢。┌─────────────┐ ┌─────────────┐│ 本服务线程池 │ │ 外部调用线程池 ││ (请求A) │ │ (请求B) │└─────────────┘ └─────────────┘ 独立运行 独立运行1.2.3.4.5.架构缺点2.1 复杂度高在进行微服务化后，每个服务可能会交给不同的团队来实现。如果管理不当，则会导致开发速度和效率降低。复杂度高 是主要挑战。 ┌────────┐ │ 团队A │ └───┬────┘ │┌────────┐ │ ┌────────┐│ 团队B │───┼───│ 团队C │└────────┘ │ └────────┘ │ ┌───┴────┐ │ 团队D │ └────────┘ (协调复杂)1.2.3.4.5.6.7.8.9.10.11.12.2.2 基础设施成本呈指数增长因为每一个微服务都有自身的成本，再加上微服务总量要比单体服务架构中的服务总量多得多，因此会产生大量的基础设施成本。基础设施成本呈指数增长。💰 成本曲线 │ │ / │ / │ / │ / └──────────→ 微服务数量1.2.3.4.5.6.7.2.3 性能下降微服务之间需要通过 RPC 或 REST 等方式进行交互。这种交互方式与单体架构中的通信方式相比，时延会受到很大的影响。时延会收到很大的影响。单体调用: [A] → [B] (本地)微服务调用: [A] → (网络) → [B] (远程) 时延↑1.2.3.设计重点在使用微服务架构进行设计时，需要关注的重点是：如何对业务需求进行拆分和设计。如果只是简单地认为微服务只是将原来的单体应用程序拆分为多个部署包或更换为支持微服务架构的技术框架，便可成为微服务；或是微服务越小越好；则设计出的系统复杂度会过高，从而导致无法进行上线和运维的情况。微服务拆分困境的根本原因在于不清楚业务或微服务的边界在哪里。业务边界─────────┌─────────┐ ┌─────────┐│ 订单服务 │ │ 用户服务 │└─────────┘ └─────────┘ 清晰分界 清晰分界1.2.3.4.5.6.总结微服务架构通过服务独立部署与线程池隔离，实现了故障隔离、独立扩展与业务逻辑解耦，显著提升系统弹性。然而，其分布式特性导致团队协调成本飙升、基础设施投入指数增长，且服务间通信引入的时延不可忽视。设计核心在于精准划定业务边界，避免过度拆分导致运维失控，同时平衡“小服务”与“简单服务”的关系。架构师需在弹性、成本与复杂度之间做出权衡，优先确保核心业务链路的稳定性与可观测性。赞 收藏 评论 分享 举报上一篇：架构设计提问和评论都可以，用心的回复会被更多人看到评论相关文章韩先超：K8S云原生技术与架构师成长之路韩先超老师，51CTO学堂K8S教学总监，拥有丰富的云计算架构经验。从普通运维到Linux运维，再到K8S架构师，韩老师在云计算领域不断突破自我。作为清华大学出版社K8S畅销书作者，韩老师在公众号和博客上分享技术知识，累计阅读量超百万。他曾参与云计算大会，分享K8S助力企业转型经验，被北京日报报道。韩老师还为多家知名企业提供K8S技术培训，积累了宝贵的实战经验。在本课程中，韩老师将结合自身多年工作经验，深入讲解K8S云原生技术，帮助学员掌握K8S架构师核心技能，助力职业发展。Kubernetes云原生微服务LinuxDocker从 OpenClaw 看 Agent 架构设计本文通过对OpenClaw，Claude Code等主流Agent产品的设计进行分析，给出Agent架构设计的关键决策，分析各方案的利弊。AIAgentOpenClawAgent架构设计SpringBoot 项目结构设计与分层架构最佳实践本文系统讲解SpringBoot项目架构设计的完整方案,深入解析标准项目结构、分层架构设计原则、统一异常处理机制、标准化响应格式封装、参数校验最佳实践以及代码规范。包含5个常见架构陷阱解决方案(分层职责混乱、异常处理不当、响应格式不统一、参数验证缺失、命名不规范)和5个性能优化技巧(分层优化、异常处理性能、响应格式优化、验证性能、架构简化),帮助开发者构建清晰可维护的企业级项目架构。适合Java后端开发者和SpringBoot学习者阅读。项目架构标准化响应格式封装分层架构设计原则统一异常处理机制最佳实践企业AI落地实战：大模型应用架构设计与方案选型随着大模型技术的成熟，越来越多的企业开始推进AI化升级。但在实际落地过程中，很多企业面临选型混乱、架构不合理、成本过高、稳定性不足等问题。本文从企业实际需求出发，讲解AI项目落地的主流架构模式、方案选型要点与实施路径，帮助企业低成本、高效率地接入AI能力。企业接入大模型主要分为两种路径：私有化部署与云端API调用。私有化部署适合数据安全性要求极高、预算充足、拥有专业技术团队的大型企业，可以完全掌限流缓存数据安全分层架构设计前言本文深入探讨优秀分层架构设计的判断标准与实践规范，涵盖各层职责划分、领域模型转换原则及常见陷阱。适合软件架构师、后端开发工程师阅读，旨在帮助读者构建高内聚低耦合、易于扩展的分层系统，提升代码可维护性。(目录)1. 架构特点优秀的分层架构设计可以通过以下几个方面来判断：便于后续开发迭代即框架(代码)的可扩展性良好。分层逻辑易于理解即其可接受面广，大家都可以快速理解其分封装领域模型业务逻辑架构设计思路前言本文介绍系统设计的四个关键步骤，从理解需求、定义边界到迭代优化，帮助读者掌握系统设计的系统化方法。适合软件工程师、架构师以及对系统设计感兴趣的开发者阅读。通过本文，你将学会如何高效地进行顶层设计与矛盾分析。(目录)1. 理解需求以及定义系统边界理解需求，核心是和产品确定功能要求，以及根据业务确定性能要求。定义系统边界，核心是要明确系统哪些要做，哪些不做。┌───────────迭代系统设计系统边界Transformer架构设计教你如何实现Transformer架构设计### 概述Transformer架构设计是一种用于自然语言处理领域的模型架构，它在NLP任务中取得了很好的效果。本文将教你如何实现Transformer架构设计。### 流程图`mermaidpie title 整体流程图 "准备数据" : 20 "构建模型" : 30 "训练模型" : 40架构设计python数据业务架构设计方法前言本文系统介绍业务架构设计中的关键方法与原则，涵盖能力/价值流映射、角色分析、应用架构设计（自上而下与自下而上）及领域建模与流程建模等核心实践。目标读者为软件架构师、技术负责人及希望提升架构设计能力的开发者，帮助读者建立从业务到技术的系统化架构思维。(目录)1.设计思路1.1 能力/价值流映射价值流: 价值流是从利益相关者（客户、最终用户或工作所产生的产品、服务或交付品的接收者）的建模解决方案架构设计Claude Code技术栈和架构设计Claude Code 是一个 Node.js 终端应用，其技术栈和架构设计体现了 Anthropic “简单先行”的产品哲学。一、Claude Code 的技术栈根据对 Claude Code npm 包的逆向分析及官方技术分享，其核心技术构成如下：技术组件用途说明Node.js运行时环境版本要求 ≥18.0.0，提供文件系统访问、子进程管理等能力TypeCodeClaude codeClaude技术栈架构实战-架构设计引言最近研究 Claude 的 System Prompt 时，发现了一个有意思的机制——Skills。表面上看，这只是"调用工具读取文件"的普通操作。但深入分析后发现，Skills 背后隐藏着一套精巧的架构设计思想，做 LLM 应用的人都应该了解。从 Skills 机制出发，本文探讨 AI 系统的模块化设计哲学，以及它与 Multi-Agent 架构的本质区别。一、什么是 Skills？Skil架构开发语言人工智能加载数据架构设计专题爆炸的现代工业现场，将成百上千个数据点杂乱地堆砌在HMI屏幕上，是对操作员认知能力的巨大挑战，尤其在压力下极易导致误判。优秀的HMI设计，本质是信息架构的设计。四层金字塔模型为此提供了一个经过验证的、符合人类认知规律的设计框架，其核心在于依据信息的优先级和操作频率进行分层，并严格控制各层的信息密度。运维数据库制造tcp/ip网络协议【技术干货】日志服务架构设计和实践掌握Dify私有化的日志分析关键方法，构建高可用日志系统。适用于企业级AI平台运维，涵盖日志采集、存储优化与实时监控三大步骤，提升故障排查效率与系统稳定性，值得收藏。数据日志采集字段微服务架构原理与开发实战_微服务架构实战本文通过代码实现展示了AI与医疗微服务的融合方案。第一章构建了一个基于FastAPI的患者注册微服务，包含FHIR标准数据模型、API端点和Docker容器化配置；第二章介绍了服务治理方案，包括使用Consul实现服务发现、通过Kong网关配置路由和JWT认证。全文采用"代码即文档"的方式，提供了一个可落地的智慧医疗平台微服务架构参考实现，覆盖从基础服务开发到安全部署的关键环节。架构人工智能微服务微服务PythonTransformer架构设计 transformer框架目录写在前面1. Transformer1.1 从哪里来？1.2 有什么不同？1.2.1 Scaled Dot-Product Attention1.2.2 Multi-Head Attention1.2.3 Masked Multi-Head Attention2. Transformer-XL2.1 XL是指什么？2.2 它做了什么？3. 小结写在前面前两天我正在微信上刷着消息，猛然间关注的几Transformer架构设计人工智能点积初始化三元组网络架构 exencoder-decoder 网络架构设计首先我们要思考网络框架应该分几层？网络框架分布式架构设计专题在媒介形态多元化与传播需求精准化的双重驱动下，企业对媒体发布系统的技术要求已从 “能发布” 升级为 “全渠道适配、高自动化、效果可量化”。传统媒体发布系统因架构陈旧、接口适配复杂、自动化程度低，难以应对 “多渠道、多形态、高并发” 的发布场景。字节探索 Infoseek 基于 “分布式架构 + AI 大模型 + 全链路数据追踪” 技术体系，构建了高性能媒体发布系统，本文从技术架构、核心模块、实现逻媒体分布式架构数据优先级插件式架构设计实践：插件式系统架构设计简介_51CTO博客Llama-Factory通过插件机制实现模型、方法、数据和接口的动态扩展，支持零侵入式集成与配置驱动加载，提升系统灵活性与可维护性，满足从初学者到高级用户的多层次需求。Llama-Factory插件机制模型微调API加载低延时直播与RTC融合架构设计③：RTC融合架构设计网易云信化，端到端延迟控制在180~190ms，支持实时结构化输出与多场景应用。Qwen3-VL-30B多模态模型实时语义分析模态结构化微服务架构关键技术专题提升Open-AutoGLM任务调度性能10倍的秘诀揭秘！本方案深入解析离线任务队列开发中的三大核心机制，适用于高并发、低延迟的AI推理场景，显著优化资源利用率与任务吞吐量。Open-AutoGLM 离线任务队列开发方案实现高效稳定调度，值得收藏。

前端- Vue3企业管理后台项目实战总结 - 个人文章 十、文档生成（VitePress）核心目标：搭建组件库的文档站，包含组件示例、API说明、快速上手等内容，方便开发者使用。步骤1：安装VitePress依赖pnpm add -D vitepress@latest markdown-it-container@latest1.依赖作用解释：依赖名作用vitepressVue官方文档工具（基于Vite，支持Markdown+Vue组件，生成静态文档站）markdown-it-containerMarkdown扩展插件（用于自定义容器，比如示例代码块、提示框等）步骤2：初始化VitePress目录结构在项目根目录创建docs目录：结构如下：docs/├── .vitepress/ # VitePress配置目录│ ├── config.ts # 核心配置文件│ ├── theme/ # 自定义主题（可选）│ │ └── index.ts # 主题入口├── components/ # 组件文档目录│ ├── button.md # Button组件文档├── guide/ # 指南文档目录│ ├── quick-start.md # 快速上手├── index.md # 文档首页1.2.3.4.5.6.7.8.9.10.步骤3：配置VitePress（docs/.vitepress/config.ts）import { defineConfig } from 'vitepress';import MarkdownIt from 'markdown-it';import container from 'markdown-it-container';import { resolve } from 'path'; // 必须引入 path 模块const md = MarkdownIt({html: true, // 允许 Markdown 中嵌入 HTML 标签 linkify: true, // 自动识别链接 typographer: true, // 启用排版优化});// 注册 demo-block 容器（格式：:::demo-block 内容 :::）md.use(container, 'demo-block', {// 自定义容器的渲染逻辑（后续可结合主题组件完善） render: (tokens: any, idx: number) => { const token = tokens[idx]; // 开始标签：::: demo-block if (token.nesting === 1) { return '<demo-block>\n'; } // 结束标签 return '</demo-block>\n'; },});// 可选：注册tip提示框容器（::: tip内容 :::）md.use(container, 'tip', {render: (tokens: any, idx: number) => { const token = tokens[idx]; if (token.nesting === 1) { return '<div class="tip-contaienr">\n'; } return '</div>\n'; },});//VitePress 主配置export default defineConfig({// ============================ 站点基础配置 ============================= title: 'Vue3组件库', // 文档站的标题（会显示在浏览器标签栏） titleTemplate: ':title - 开箱即用的vue3组件库', // 标题模板（可选，格式：[页面标题] - [站点副标题]） description: '基于Vue3+TS+Vite构建的后台管理系统公共组件库，提供丰富的UI组件和完整的类型支持', //站点描述（SEO用） base: '/vue3-component-library/', // 部署基础路径（重要！） lang: 'zh-CN', // 站点语言（默认zh-US，推荐设为 zh-CN） cleanUrls: true, // 启用干净的 URL（去掉 .html 后缀，如 /guide/quick-start 而非 /guide/quick-start.html） // ============================ 主题配置（内置主题） ====================== themeConfig: { // 站点logo logo: '/vite.svg', // 站点导航栏右侧的深色/浅色模式切换 darkModeSwitchLabel: '主题', // 导航栏右侧的与语言切换（若需要多语言） langMenuLabel: '语言', // 顶部导航栏（Nav）配置 nav: [ { text: '指南', // 导航栏文字 link: '/guide/quick-start', // 点击跳转的路径（对应 docs/guide/quick-start.md） // 可选：下拉菜单（若指南有多个子页面） // items: [ // { text: '快速上手', link: '/guide/quick-start' }, // { text: '配置说明', link: '/guide/config' }, // ], }, { text: '组件', link: '/components/button', // 可选：下拉菜单（组件较多时） // items: [ // { text: 'Button 按钮', link: '/components/button' }, // { text: 'Input 输入框', link: '/components/input' } // ] }, { text: 'GitLab', // 可选：链接到 GitHub 仓库 link: 'https://jihulab.com/chj_158-group/vue3-component-library.git', target: '_blank' // 新标签页打开 } ], // 侧边栏（Sidebar）配置：按路径分组（不同目录显示不同侧边栏） sidebar: { // 指南目录（/guide/ 开头的路径）的侧边栏 '/guide/': [ { text: '指南', // 侧边栏组标题（可选，不写则无分组） collapsed: false, // 是否默认折叠（false 为展开） items: [ { text: '快速上手', link: '/guide/quick-start' }, // 对应 quick-start.md // 可选：添加更多指南页面 // { text: '按需引入', link: '/guide/按需引入' }, // { text: '主题定制', link: '/guide/主题定制' } ], }, ], // 组件目录（/components/ 开头的路径）的侧边栏 '/components/': [ { text: '基础组件', collapsed: false, items: [ { text: 'Button 组件', link: '/components/button' }, // 可选：添加更多组件 { text: '智能体 组件', link: '/components/agent' }, // { text: 'Card 卡片', link: '/components/card' } ] } ] } }, // ============================ Vite 配置（继承扩展Vite配置）=============== vite: { // 解析配置：路径别名（让文档中能直接引用 src 目录的组件） resolve: { alias: { // 把 @ 指向项目根目录的 src 目录（关键！这样在md中可以 import Button from '@/components/Button/Button.vue'） '@': resolve(__dirname, '../../src'), // 可选：添加其他别名 // 'vue3-component-library': '/src' } }, // 可选：开发服务器配置 server: { port: 5174, // 自定义文档开发服务器端口（默认 5173，若被占用可修改） open: true // 启动时自动打开浏览器 }, // 可选：构建配置 build: { chunkSizeWarningLimit: 1000 // 增大 chunk 大小警告阈值（默认 500kb） } }, // ===================== Markdown 配置 ===================== markdown: { // 传递自定义的 Markdown 解析器（我们之前注册了 demo-block 容器） renderer: md, // 可选：启用代码行号 lineNumbers: true, // 可选：配置 Markdown 插件 config: (md) => { // 可在这里注册更多 Markdown 插件（如 markdown-it-emoji 表情插件） // md.use(require('markdown-it-emoji')); } }})1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.61.62.63.64.65.66.67.68.69.70.71.72.73.74.75.76.77.78.79.80.81.82.83.84.85.86.87.88.89.90.91.92.93.94.95.96.97.98.99.100.101.102.103.104.105.106.107.108.109.110.111.112.113.114.115.116.117.118.119.120.121.122.123.124.125.126.127.128.129.130.131.132.133.134.135.136.137.138.139.140.141.142.143.144.145.146.147.上图是我的初版配置项 ，可根据自己的项目进行更改。步骤4：编写文档内容（1）首页（docs/index.md）首页布局配置（固定格式）layout: home页面标题（会覆盖站点标题）title: Vue3组件库页面描述（会覆盖站点描述）description: 基于Vue3+TS+Vite构建的后台管理系统公共组件库 import { ref } from 'vue'; // 可选：在首页引入组件（如展示一个按钮示例） import { Button as VButton } from '@/components'; const code = ` 立即使用