最近把这几年的项目经验和技术选型整个摊开做了一次大盘点发现一个很有意思的现象技术栈这个词被用得越来越宽泛但大多数人理解的技术栈就是简历上那一串名词——Vue、React、Node.js、MySQL、Docker平铺罗列看不出主次也看不出关联。真正有价值的技术栈全景图应该是一张能看到层次、依赖和演进方向的架构图。恰好这几天有不少人在搜AGV技术栈有哪些用uniapp做小程序用到的技术栈electron技术栈这三个方向也覆盖了我这几年工作里最典型的几类场景工业智能硬件、跨端小程序、桌面客户端。这篇文章我就用这三个领域当样本说说我是怎么拆解、记录和维护自己的技术栈全景图的。如果你刚入行可以把它当成梳理个人知识体系的模板如果你已经带项目了也许能帮你找到团队技术规划里的盲区。1. 先把技术栈清单升级成技术栈全景图区别在哪1.1 清单只是名词堆砌全景图是分层架构我面试人的时候有个习惯看到简历上技术栈写得满满当当的会先问一句你最近半年真正在用的有哪些。这不是刁难而是想判断对方是把技术栈当成名词集合还是真的理解技术之间的位置关系。技术栈全景图和工具清单最大的区别是它包含位置和关系两个维度。什么是位置拿盖房子举例。钢筋水泥是结构层水电管线是功能层墙面粉刷是装饰层。你不能只说我用了钢筋、水管、油漆你得知道钢筋负责承重、水管负责走水、油漆负责防潮。技术栈也一样底层架构解决运行和扩展问题中间框架解决业务开发效率顶层应用解决用户具体需求工具链解决协作和交付。每一层的位置决定了它的选型标准——底层的稳定性和生态成熟度优先上层的开发效率和团队熟悉度优先。什么是关系关系包括谁依赖谁和谁能替换谁。比如业务层依赖框架层的Vue框架层依赖运行时层的JavaScript引擎运行时层跑在基础设施层的容器里。当你想把Vue换成React受影响的是组件和状态管理但不会动到底层容器反过来如果想把Node.js运行时整个换掉那上面的框架和业务代码全都要重写。画全景图时我会把这种依赖关系标清楚一旦底层要升级心里立刻有数。1.2 一张好全景图的三个特征我自己盘点技术栈时会看三件事。一是可见性。核心技术和边缘技术一眼要能分出来。拿uni-app项目来说Vue语法、uni-app API、微信小程序运行机制是核心某个工具库、某个临时插件是边缘。核心决定项目的生死边缘决定开发效率两者的关注优先级完全不同。核心技术要有深入理解和复盘复盘边缘技术只需要知道何时引入、何时替换。二是关系性。技术之间不是孤立存在的。比如用了uni-app的Vue3版本状态管理选Pinia还是Vuex就有关系组件库是否兼容uni-app的easycom规范也要在选型时确认。画图时把这些连接标出来换技术时就能评估连带影响——这个我后面讲Electron技术栈时会详细展开。三是演进性。技术栈是动态的不是刻在石碑上的。我见过不少团队的技术栈全景图半年不更新实际代码里早就引入了新的请求库、新的状态管理方案图上却还停留在老状态。好的全景图应该记录正在用的正在换的准备淘汰的三种状态每年至少复盘一次。1.3 用全景图反推学习路线和团队规划新人经常问我到底该学什么我一般不建议按热搜排行榜学而是建议先画一张目标岗位的技术栈全景图再看自己的缺口在哪。比如想进入小程序开发可以先从Vue语法、uni-app框架、项目工程化、小程序平台API这四层逐层补齐。缺哪补哪比漫无目的地刷教程路径要短得多。团队技术规划也一样。我每次接一个新项目第一周很少急着写代码而是先把项目的技术栈全景图画出来标注哪些模块缺人、哪些依赖有隐患、哪些技术快过时了。有了这张图排期和招聘需求都会变得很清晰。这个习惯是我踩过不少坑之后才养成的。2. 一张AGV机器人项目的技术栈全景图怎么画2.1 AGV系统技术栈的六层结构AGV是自动导引车就是仓储、工厂车间里运货的那类机器人。很多人问AGV技术栈有哪些如果只回答ROS、SLAM、C那基本等于没说。我参与过AGV项目最大的体会是AGV是典型的交叉学科项目技术栈横跨嵌入式、算法、后端和前端任何一个单点技术都撑不起整个系统。我习惯把AGV项目的全景图分成六层感知层激光雷达、IMU惯性单元、编码器、视觉相机、磁条传感器、二维码读头决策与调度层任务分配、路径规划、多车交通管制控制执行层运动学解算、伺服控制、电机驱动、PLC/嵌入式实时控制通信层WiFi/5G、工业以太网、CAN总线、MQTT/Modbus协议上位管理层车队监控平台、地图配置工具、任务管理后台、告警系统运维与仿真层日志采集、远程OTA、数字孪生模拟、回归测试具体到选型我整理过一张参考表层级常用技术说明感知层C、Linux、ROS/ROS2、SLAM库多传感器融合定位常见方案是激光IMU码盘决策调度层Java/Go/C、Redis、RabbitMQ/Kafka调度核心要处理高并发任务和状态同步控制执行层C语言、STM32平台、FreeRTOS、伺服驱动实时性要求高响应要到毫秒级通信层MQTT、TCP/UDP、工业总线协议跨设备通信稳定性比带宽更重要上位管理层Vue/React、WebSocket、ECharts、MySQL前端实时展示车辆位置和任务进度运维仿真层Docker、Prometheus/Grafana、MATLAB/Simulink现场问题定位和运行验证有些团队会把SLAM单独拿出来讲我理解但实际项目里SLAM只是感知层的一部分。AGV真正难的地方是把传感器数据转换成可执行的移动指令这个过程横跨感知、决策、控制三层不是某一个算法库能包圆的。2.2 关键选型经验嵌入式、算法、调度端怎么搭先说控制执行层。底层实时控制推荐STM32配合FreeRTOS这类RTOS跑运动学解算和伺服控制。AGV底盘的常见构型是差速轮或麦克纳姆轮解算逻辑本身不复杂但必须在固定周期内执行否则车体就会抖动。工业环境电磁干扰多硬件设计上的问题——比如编码器信号滤波、布线走向——经常会反向影响软件表现这个领域真要软硬打通不能只盯代码。调度层是AGV车队化的关键。单台车不难走多台车同时作业才会暴露问题任务分配给哪台车、路径是否冲突、路口让行顺序怎么定。调度模块通常用Java或Go做配合Redis存车辆实时状态用消息队列缓存任务。路径规划最常用的是A*和Dijkstra的变体再加上时间窗算法来避免多车碰撞。对AGV来说所谓最优路径不一定是全局最短而是在正确时间窗口内不与其他车冲突的路径——这两者在调度系统里常常不是一回事。上位管理平台是用户直接操作的部分。前端要实时查看车辆位置、任务进度、告警信息。场地地图如果是二维栅格用Canvas或ECharts就能画得很清楚如果要做3D仿真监控才需要考虑Three.js级别的方案。后端接口设计要特别注意状态同步的实时性我常用的方式是前端轮询加WebSocket推送组合低频数据走轮询位置和高频告警走WebSocket这样既省资源又能保证关键信息及时到达。2.3 现场项目里最容易翻车的两个环节第一个是WiFi漫游。AGV在车间里移动经常从一台AP漫游到另一台AP漫游切换的瞬间会有丢包调度指令卡一下车辆就可能急停或者走错位置。我在现场调试时都会要求通信组在车间关键路径上做无线覆盖优化项目初期就要做漫游测试别等上线了才暴露。第二个是调度系统里的逻辑死锁——两台车在狭窄通道里迎面相遇互相等对方让路结果谁也无法继续。这个问题靠单车的路径规划程序解决不了必须在调度层设计冲突检测和回退策略比如设定等待超时、进入让路模式、由调度服务器统一裁决。真实的AGV项目调度层日志量非常大我强烈建议现场部署完整的日志采集体系出了问题先看日志回放能省一半排查时间。3. 用uni-app做小程序全景图不只是Vue语法3.1 从语法到运行完整的技术栈分层搜用uniapp做小程序用到的技术栈很多回答只会写Vueuni-app。这当然没错但它大概率只看到了第一层。我做一个uni-app项目时的全景图大概分六层语法基础HTML/CSS/JavaScript、Vue3语法、TypeScript建议上尤其代码共享多的场景框架能力uni-app生命周期的平台差异、条件编译、easycom组件规范、路由与页面栈运行平台微信小程序、App端、H5端每端有自己的限制工程化HBuilderX或Vite CLI、ESLint、状态管理、依赖和构建业务封装请求库、登录鉴权、上传下载、缓存策略、埋点统计发布运维微信后台配置、证书、分包上传、线上数据监控对很多小程序团队来说最容易忽略的是运行平台这一层。同样的代码在微信小程序里跑要遵守小程序的包体积规则在App里跑要处理系统权限和原生能力差异在H5端跑又依赖浏览器特性。uni-app的价值是把跨端差异集中在框架层但开发者仍然要了解每端的红线在哪里否则上线时会被各种平台限制打得很被动。3.2 工程化细节状态管理、组件库、请求封装如果项目用Vue3语法状态管理建议直接用Pinia写法比Vuex简洁uni-app的兼容性也验证过没问题。组件库方面优先选uni-app生态内的组件库比如uview-plus这类因为它们直接遵循easycom规范引入后自动按需加载不用每个页面手动import。说实话中小型项目不引入第三方UI组件库完全可以uni-app内置组件够用UI库最大的价值其实是帮团队统一交互规范而不是单纯提供几个按钮。请求封装我用过一个比较顺手的模式基于uni.request包一层request.js在拦截器里统一加token、处理过期跳转登录、统一弹出错误提示。要注意的是uni.request不像axios那样自带拦截器需要自己封装。跨端场景下不要依赖某个平台特有的API比如不要在封装里直接写微信的wx.request要走uni的统一接口否则后续想发布到App端就要返工。下面是一段条件编译的写法跨端时非常实用// #ifdef MP-WEIXIN const platformName weapp // #endif // #ifdef APP-PLUS const platformName app // #endif // #ifndef H5 console.log(当前不是H5环境) // #endif这种写法在uni-app里很常规但有个坑要提醒条件编译是按平台注释识别的配置写错了不会报错只会导致某个端行为异常。我一般会在条件编译的代码块里加醒目的注释避免后续维护的人改错。3.3 多端适配与发布链路里的坑小程序发布最常见的限制是包体积。微信主包默认2MB超过就要分包。我们的做法是按业务模块拆分包主包只放首页、公共组件和登录相关页面。图片资源不要直接打包进项目CDN化既能减包又能提速。真机预览和模拟器表现经常不一致尤其是地图、扫码这类系统能力我强烈建议每轮功能都安排真机自测别等提审时才手忙脚乱。还有权限配置的问题。uni-app做小程序时涉及蓝牙、定位、摄像头权限不同端申请的时机和文案都不一样。比如微信小程序需要先在manifest里声明权限调用时再弹窗H5端走的是浏览器权限机制。这些差异要在开发前期就考虑清楚上线后才发现会非常被动。4. 深入Electron技术栈主进程、渲染进程和那些构建工具4.1 先把架构理解透三个角色一条消息通道Electron技术栈和普通前端项目最大的不同在于它有一个双进程加桥接的模型。主进程负责窗口管理、系统能力、Node.js底层操作渲染进程负责页面UI交互。两者之间通过IPC通信preload脚本则是中间桥梁。安全配置上现代Electron应用强烈建议开启contextIsolation、关闭nodeIntegration把需要暴露给页面的能力通过contextBridge逐一注入。我见过直接把nodeIntegration改成true的旧项目看起来图省事实际上让任何XSS漏洞都能直接操作文件系统风险非常大。preload脚本大概长这样const { contextBridge, ipcRenderer } require(electron) contextBridge.exposeInMainWorld(desktop, { readFile: (filePath) ipcRenderer.invoke(file:read, filePath), minimizeWindow: () ipcRenderer.send(window:minimize) })理解这个模型之后很多开发中的困惑都能解开为什么渲染进程里不能用Node模块因为沙箱和安全配置。为什么功能要拆到主进程因为窗口卡顿往往是渲染进程做了重活。主进程不是不能写业务而是只应该做只有主进程能做的事其他逻辑都放手给渲染进程或子任务。4.2 工程化与打包分发怎么选工具先给一个工具选型对比工具定位适用场景electron-vite开发脚手架速度优势明显新项目推荐Vite插件生态好electron-forge官方推荐的全流程工具深度集成Electron插件体系完整electron-builder打包发布为主配置灵活NSIS/AppImage格式支持好我自己的组合偏好是用electron-vite搭开发环境用electron-builder做打包。开发阶段热更新快不快直接影响体验electron-vite这块做得很好打包阶段electron-builder的配置比较成熟。要注意的是electron-updater自动更新和代码签名是两件事Windows上如果不做代码签名更新包容易被系统安全提示拦截这个坑让我在交付现场被卡过多次。打包体积也是Electron的老话题。内置Chromium和Node让安装包天生很大一个空白应用也接近80MB。我做过一次优化结论是去掉不必要的依赖、使用asar压缩、选择合适的安装包格式能把体积降一些但想降到原生桌面应用那个量级基本不可能。选Electron时要把这个体积成本算进产品决策里这也是技术栈全景图里需要提前标注的隐性成本。4.3 桌面端独有的性能和安全问题渲染进程崩溃是Electron应用最头疼的问题之一。做过网页的人很少关注页面崩溃因为刷新一下就好但桌面应用刷新会丢用户状态。我一般会监听渲染进程的crash事件弹窗提示用户并保留内存中的日志必要时自动重启窗口。主进程性能也要重点留意。主进程里的同步I/O或大计算会把整个应用卡死因为所有窗口都依赖主进程的事件循环。同步操作能用异步就绝不写同步CPU密集任务放到worker_threads或child_process。还有一个容易被忽略的点定时器要在窗口销毁时清理干净。我之前遇到一个后台任务导致应用无法退出的问题查了半天才发现是某个定时器没清。安全问题再强调一次禁用nodeIntegration、开启沙箱、配置CSP、对外部页面保持最高谨慎。桌面应用有完整文件系统权限一旦出现XSS后果跟网页端不是一个量级。这属于技术栈全景图里底线型配置每个Electron项目进场第一天就要检查。5. 我维护个人技术栈全景图的习惯和原则5.1 我的记录方法与年度复盘我自己的技术栈全景图主要记录在个人知识库里一个Markdown文件搞定按层级分五个区域核心运行时、常用框架、工程工具、业务中间件、正在观察的技术。每个区域下标注熟练度和最近使用时间。维护规则很简单每季度花十分钟更新一次每半年做一次大清理。清理标准就一条——最近6个月没有实际使用过的技术要么标为生疏要么移入草稿区。这样做能保证全景图永远是可信的而不是一份自嗨清单。我见过一些工程师简历上写了十几种技术栈面试时一问细节就露馅反而影响整体可信度。5.2 选型三原则生态、团队、任务技术选型我会按三个维度打分生态成熟度、团队熟悉度、业务匹配度。生态要看项目的活跃度和长期维护能力。star数量和npm下载量只是入门指标更要看社区能不能解决你的具体问题、有没有足够的第三方方案兜底。团队熟悉度决定学习成本和排期风险一个更好但没人会用的技术栈在交付压力下就是灾难。业务匹配度是最后一道尺子——做图像识别的项目选Python和深度学习框架做高并发网关选Go做电商后台选Java生态都是常见且理性的选择。三个维度都能站住脚的技术栈用起来才不心虚。5.3 两次技术栈换血的复盘第一次是从Vue2迁移到Vue3。团队起初觉得Vue2足够稳定但新需求越来越多Composition API对复杂逻辑的复用优势实在明显。迁移过程中最大的成本不是语法差异而是第三方组件库的兼容性——有的老组件库长时间不更新对Vue3支持不完善我们临时换了一版组件库页面样式全部要微调。第二次是从webpack换到Vite。开发热更新从几秒降到几百毫秒体验天差地别。但要注意Vite的依赖预构建机制一些老项目里写法不规范的CommonJS模块可能在生产构建时报错。我的建议是换工具链不要只盯着构建日志要在全量代码跑一遍冒烟测试尤其是老项目。这两次换血的共同经验是技术栈升级不是简单替换要评估整个关系网络的连带影响——组件库、插件、构建脚本、CI流程每个环节都可能藏着坑。所以我在全景图里会专门用一节记录正在迁移中的技术方便随时追踪影响边界。5.4 用核心工具箱和雷达图两张图管理个人技术栈最后分享一个我个人的小习惯。我会同时维护两张图一张叫核心工具箱里面只放最近半年真正在用的技术要求是自己能不看文档就讲清楚原理另一张叫雷达图放正在学习、正在调研、浅尝辄止的技术标注来源和当初想解决的问题。核心工具箱要小越小越精越能代表硬实力。雷达图要大大意味着保持着技术视野。那些想学但还没投入时间的框架不要急着写进简历先在雷达图里待着。等某个业务场景真的需要它时再把它从雷达图提升到工具箱。如果你看完这篇文章想动手做点什么我的建议是先别急着学新框架。拿一张纸把你最近半年真正在用的技术写下来按运行时、框架、工程、中间件、工具分五层填进去。填完你会发现属于你的技术栈全景图其实已经很有内容了——缺的从来不是技术本身而是把技术整理成体系的那张图。