Vue3 + Vite + ECharts 大屏项目全流程实战指南-北京尧图网络

做可视化大屏也有一些年头了前后经手的Vue大屏项目少说也有十来个。从最早用jQuery拼图表到后来Vue2 ECharts全家桶再到现在的Vue3 Vite TypeScript组合踩过的坑比走过的路都多。经常有同行问我大屏项目到底怎么搭才省心这里统一整理一篇全流程实战心得从项目初始化讲到部署上线把能够直接抄作业的细节和思路都给你。先说一个很实际的问题大屏项目到底难在哪里我的体感是大部分难度不在图表怎么画而在分辨率适配、数据刷新策略、模块间通信、打包部署这几件看似基础的事情上。很多项目前期看着挺顺一上真机或者部署到服务器就出各种问题——要么布局乱了要么数据不动了要么视频流黑屏。这些问题完全可以在开发阶段提前规避。这篇内容适合正在接触大屏开发的前端同学也适合Vue基础不错、想系统了解大屏项目完整链路的人。文章里的方案都是我实际验证过的你直接照着做可以少走不少弯路。1. 大屏开发的前期准备与整体设计1.1 理清需求类型大屏并不只是“图表集合”开始写代码之前先搞清楚你手头的大屏属于哪种类型。我通常把大屏项目分成三类数据展示型以图表、指标卡、排名列表为主偏向“看得清楚”比如业务数据总览、销售战报。这种大屏对UI美观度要求高但交互简单数据刷新一般靠定时轮询就够。综合监控型大屏上往往包含地图、设备状态、告警列表、视频画面偏向“看得及时”比如机房监控、园区管理、工厂产线。这种大屏对数据实时性要求高通常要接WebSocket或者视频流。指挥调度型接近监控型的升级版除了数据可视化还涉及下发指令、操作设备、多人协作。这种项目不能只考虑“展示”还要设计足够的交互入口和状态管理方案。不同需求类型决定了你的技术选型。比如纯数据展示型轻量轮询就能解决没必要上WebSocket而综合监控型如果只用轮询告警延迟会很难看。需求分析的结果直接影响后续的架构设计这是我在项目里摔过跟头才明白的。1.2 技术选型为什么我推荐Vue3 Vite ECharts组合关于大屏技术栈我的建议非常明确新项目优先选Vue3 Vite TypeScript ECharts Pinia理由如下。Vue3的组合式API天然适合大屏这种“功能模块多、代码按业务聚合”的场景。大屏页面通常一个页面塞了很多功能区块用Options API写起来组件越来越胖而组合式函数可以把某一块业务完整抽离比如获取数据、处理数据、控制图表更新都放在一个函数里组件只负责组合。Vite的启动速度在开发大屏时特别关键。大屏项目图表多、依赖多Webpack工程改动一下热更新要等好几秒Vite几乎秒开开发体验不是一个级别。ECharts在大屏领域的统治力目前依然无可替代。虽然AntV G2、G6在某些场景更优秀但ECharts的社区案例、文档丰富度、调试工具对大屏场景来说最省心。特别是它的graphic组件用来做背景装饰、dataset用来做数据驱动更新都是大屏高频能力。1.3 目录结构从一开始就把模块边界划清楚大屏项目如果不规划好目录很容易变成“一个巨大的组件里塞满了各种逻辑”。我常用的一版目录结构你可以参考src/ ├── api/ │ ├── modules/ │ │ ├── dashboard.ts │ │ └── monitor.ts │ └── request.ts ├── assets/ ├── components/ │ ├── dashboard/ # 业务组件 │ │ ├── ChartCard.vue │ │ ├── StatusBoard.vue │ │ └── MapPanel.vue │ └── common/ # 通用组件 │ ├── ScreenAdapter.vue │ ├── DigitalFlop.vue │ └── ScrollList.vue ├── composables/ # 组合式函数 │ ├── useScreenAdapter.ts │ ├── useChart.ts │ └── useWebSocket.ts ├── layouts/ │ └── ScreenLayout.vue ├── router/ ├── store/ └── views/ └── dashboard/index.vue这个结构其实是“按业务模块按功能类型”混合划分。components/dashboard下放该业务独有组件components/common下放能复用的基础组件composables放跨组件复用的逻辑。这样切分的好处是当大屏页面要增加一个新功能区块时你明确知道该把代码放哪里、该复用哪些现成逻辑。2. 环境搭建与工程化配置2.1 Node.js版本与包管理器选择大屏项目开发环境的第一步是装好Node.js。这里有个很务实的建议不要用太老的版本也不要刻意追最新。目前建议使用Node.js 18 LTS 或 20 LTS这两个版本对Vite 5 的支持稳定构建速度和兼容性都处于最佳状态。包管理器我推荐pnpm。在大屏项目里依赖很多ECharts、组件库、地图库等pnpm的硬链接机制可以避免重复下载几百MB的依赖包安装速度比npm快非常多而且天然规避了“幽灵依赖”问题。如果团队统一用npm也没问题但建议至少在开发环境跑一下npm pnpm的性能对比用一次就知道差距了。2.2 快速创建Vue3工程并安装依赖使用Vite创建项目pnpm create vite vue-screen-demo --template vue-ts cd vue-screen-demo pnpm install然后安装大屏项目常用依赖pnpm add echarts pinia vue-router axios pnpm add -D sass unplugin-auto-import unplugin-vue-components有几个点解释一下sass虽然现在CSS有原生变量但大屏项目里深色背景、渐变边框、透明遮罩用得非常多sass的嵌套语法和混合宏能省很多重复代码。unplugin-auto-import 和 unplugin-vue-components这两个插件可以自动导入Vue API和组件库按需引入比如Element Plus或Naive UI。大屏项目图表配置代码量巨大如果还要手动在每页 import ref、reactive代码会显得很啰嗦。TypeScript有的团队嫌麻烦引入TS但大屏项目数据结构复杂图表配置、接口协议TS能把潜在的字段拼写错误提前暴露在数据驱动界面刷新的大屏场景里按我的经验尤其值得。安装完成后在vite.config.ts里做一些基础配置import { defineConfig } from vite import vue from vitejs/plugin-vue import AutoImport from unplugin-auto-import/vite import Components from unplugin-vue-components/vite export default defineConfig({ plugins: [ vue(), AutoImport({ imports: [vue, vue-router, pinia] }), Components({ dirs: [src/components] }) ], resolve: { alias: { : /src } }, server: { host: 0.0.0.0, port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这里server.proxy很重要。大屏项目开发阶段如果跨域没配好接口请求经常被浏览器拦截白白浪费排查时间。2.3 环境变量分环境管理大屏项目通常有开发环境、测试环境、生产环境不同环境对应不同的后端接口地址和WebSocket地址。Vite的环境变量机制做得非常直观创建以下文件.env.development .env.production内容格式如下VITE_API_BASE_URL/api VITE_WS_URLws://192.168.1.100:8080/ws然后在代码里用import.meta.env.VITE_API_BASE_URL读取在src/api/request.ts里统一封装axiosconst service axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 10000 })这里我遇到过不少人把接口地址硬编码在组件里一旦切换环境就要全局搜索替换效率极低。环境变量文件的好处是打包的时候Vite会按mode自动加载对应文件一套代码直接出多环境产物不用改任何业务代码。还有一个经常被忽视的问题import.meta.env变量如果要在vite.config.ts里读取需要借助loadEnv函数因为配置文件本身不经过环境变量插值。但在src业务代码里直接用即可。3. 大屏核心功能实现自适应、可视化与数据刷新3.1 分辨率适配scale缩放方案与rem方案的取舍大屏最令人头疼的就是分辨率适配。常见的屏幕有1080P、2K、4K还有特殊比例的拼接屏如果只做一套像素方案换屏必乱。目前主流方案有两条路我用对比的方式讲清楚。第一种是固定尺寸 transform缩放。设计稿按1920x1080做页面整体在index.html里用#app容器的transform: scale()缩放适配实际屏幕。核心代码如下function useScreenAdapter(w 1920, h 1080) { const scaleX window.innerWidth / w const scaleY window.innerHeight / h const scale Math.min(scaleX, scaleY) document.getElementById(app).style.transform scale(${scale}) document.getElementById(app).style.transformOrigin left top }这个方案的优点是开发时完全不用考虑屏幕尺寸所有像素值按照设计稿写死最直观缺点是缩放会导致模糊或留黑边而且缩放后图表的tooltip点击位置会有偏移因为鼠标坐标和缩放后的DOM坐标不一致。第二种是rem 动态设置根字号。页面布局宽度用rem表示再通过JS根据屏幕宽度动态调整html的font-size。比如document.documentElement.style.fontSize window.innerWidth / 1920 * 100 px这样1rem 1% 的设计稿宽度布局会随屏幕宽度等比拉伸。但问题在于高度方向如果设计稿是16:9在超宽屏上依然会有上下居中的区域需要处理而且对图表的适配逻辑不太友好。我的实际经验是如果你只做一块固定比例的屏幕用scale缩放就够了如果你要做适配多种终端的响应式大屏用rem方案并把图表尺寸计算放在resize事件里。大多数项目我采用的其实是“layout整体scale chart按宽高自适应”的混合方案——外部容器做比例缩放图表内部监听resize事件按实际像素重新渲染。无论选哪种都要记得在window的resize事件里执行适配逻辑并用防抖处理300ms否则频繁触发会导致图表重绘卡顿。3.2 ECharts图表接入按需引入与性能细节ECharts全量包大约1MB以上大屏项目对首屏加载速度是有要求的所以要按需引入。我的做法是在src/utils/echarts.ts里统一注册需要的模块import * as echarts from echarts/core import { BarChart, LineChart, PieChart } from echarts/charts import { TitleComponent, TooltipComponent, GridComponent, LegendComponent, DataZoomComponent, GraphicComponent } from echarts/components import { CanvasRenderer } from echarts/renderers echarts.use([ BarChart, LineChart, PieChart, TitleComponent, TooltipComponent, GridComponent, LegendComponent, DataZoomComponent, GraphicComponent, CanvasRenderer ]) export default echarts这里有个关键点TooltipComponent大屏里几乎必须用没有它图表鼠标悬停就没提示DataZoomComponent在时间轴、榜单滚动场景非常常用GraphicComponent用来在图表上覆盖文字、图片装饰做数据大屏背景时很好用。大屏图表的渲染性能上我还有几个经验关闭动画大屏上线后是不需要看动画的动画只适合开发调试。初始化图表时animation: false能明显降低CPU占用尤其是页面有十几个图表时多动画同时播放在低配工控机上会卡得怀疑人生。复用实例同一个图表容器不要反复init和dispose创建后只通过setOption更新数据。每次dispose再重建会带来内存碎片和卡顿。合理做法是页面初始化时统一创建图表实例数据更新时只替换series.data和xAxis.data。大数据量场景开启采样如果数据点上千给series加上sampling: lttbECharts会做降采样渲染效率提升非常显著。3.3 数据通道设计轮询 WebSocket 双通道大屏的数据刷新是整个项目的动力核心。我见过太多项目单纯用setInterval每隔几秒请求一次接口数据量大或者接口慢时就会出现“闪烁”、“空白”或“数据错乱”。我的推荐方案是双通道数据设计。常规数据指标卡、排行榜、图表走定时轮询使用一个统一的调度器管理。比如每5秒或10秒拉取一次聚合接口更新时间错开避免同时发大量请求。高实时性数据告警、状态变化走WebSocket推送服务端主动下发变更事件前端收到事件后局部更新对应模块。这种分工的依据是大屏上“秒级变化”的数据通常是极少数让所有数据都走长连接既浪费资源又增加后端复杂度但所有数据都靠轮询实时告警类的数据又会延迟严重。折中方案是能接受就轮询不能接受就单独走WS推送。WebSocket在Vue大屏里的封装核心是处理断线重连和心跳检测。这里给出一个我在useWebSocket组合函数里的关键实现function initWebSocket(url) { let ws: WebSocket | null null let heartbeatTimer: number | null null let reconnectTimer: number | null null let manualClosed false const connect () { ws new WebSocket(url) ws.onopen () { console.log(WS connected) if (reconnectTimer) clearTimeout(reconnectTimer) heartbeatTimer setInterval(() { ws?.send(JSON.stringify({ type: ping })) }, 30000) } ws.onclose () { if (heartbeatTimer) clearInterval(heartbeatTimer) if (!manualClosed) { reconnectTimer setTimeout(() connect(), 5000) } } ws.onerror (err) { console.error(WS error, err) ws?.close() } } const close () { manualClosed true ws?.close() } connect() return { close } }断线重连间隔用5秒心跳30秒一次这是比较均衡的配置。注意要在组件卸载时主动close()并且把manualClosed置为true否则切路由后WebSocket还在后台重连会白白消耗浏览器资源。3.4 视频流接入m3u8播放实测记录大屏项目经常要接入监控视频流我用过的最多的格式是HLS即m3u8。在Vue3里播放m3u8目前最可靠的方式是hls.js库。安装pnpm add hls.js在组件中封装一个简易播放器import Hls from hls.js const videoRef refHTMLVideoElement() function setupHls(url: string) { if (!videoRef.value) return if (Hls.isSupported()) { const hls new Hls({ enableWorker: true, lowLatencyMode: true }) hls.loadSource(url) hls.attachMedia(videoRef.value) hls.on(Hls.Events.ERROR, (_, data) { if (data.fatal) { // 出现致命错误尝试恢复 if (data.type Hls.ErrorTypes.NETWORK_ERROR) { hls.startLoad() } } }) } else if (videoRef.value.canPlayType(application/vnd.apple.mpegurl)) { // Safari原生支持 videoRef.value.src url } }播放m3u8时容易踩两个坑跨域问题视频流地址如果和页面域名不一致需要在视频流服务端配置CORSAccess-Control-Allow-Origin否则浏览器会拦截。这个排查起来视觉表现为“一直黑屏、无报错或报跨域错误”。视频流卡顿如果公网带宽有限多路视频同时播放会卡顿。解决办法是按需播放——默认只加载首帧或暂停状态点击某路画面时才真正开始播放。另外可以给video元素添加preloadnone属性避免加载不需要的资源。4. 路由、布局与组件封装细节4.1 大屏项目路由设计与参数传递大屏项目通常有多个页面总览大屏、分屏详情、历史趋势页。路由设计上我的建议是使用“平铺命名视图”的方式{ path: /screen, component: () import(/layouts/ScreenLayout.vue), children: [ { path: , name: overview, component: () import(/views/dashboard/index.vue) }, { path: detail/:id, name: detail, component: () import(/views/dashboard/detail.vue) } ] }这里的:id是路由参数在详情页里通过route.params.id获取。大屏项目中经常需要在总览页点击某个模块跳转到对应的详情大屏同时把当前时间和筛选条件带过去。我建议用query传递筛选条件用params传递标识IDrouter.push({ name: detail, params: { id: device-001 }, query: { startTime: 2025-01-01, endTime: 2025-01-02 } })这样刷新页面时路由参数会保留在URL上刷新后页面状态不丢失这一点对大屏“长时间挂着”的场景特别重要。4.2 路由拦截器大屏权限与登录校验很多大屏项目部署后并不需要登录鉴权但一旦涉及后台管理或者有“多角色看不同大屏”的需求路由拦截器就是必须的。我通常在src/router/index.ts里加全局前置守卫router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next({ name: login }) } else { next() } })在大屏项目里建议把敏感数据接口的鉴权逻辑也统一放到axios的请求拦截器中前端只做“跳转拦截”真正的数据权限以后端校验为准。也就是说前端是为了体验后端才是安全底线。4.3 公共组件封装图表组件、边框组件、滚动列表开发大屏时公共组件的设计直接影响开发效率。我总结下来最值得封装的四个组件ChartCard容器带标题栏、边框、内容区的容器统一图表的间距和样式。如果项目里用ECharts还可以把这个容器和图表实例绑定自动处理init和resize。数字翻牌器大屏上显示大数字经常要做数字滚动动画。可以用Composition API暴露setValue方法内部通过requestAnimationFrame实现平滑递增。滚动列表排行榜、最新告警列表常用自动滚动效果。基于CSS动画或JS定时器实现注意在鼠标悬停时暂停滚动、离开后恢复。状态指示灯 / 图标标签设备在线状态、告警级别的展示。这类小组件虽然小但统一封装后能保证视觉一致性。封装图表组件时我的核心思路是组件只负责“把图表配置和容器绑定”不负责数据获取。数据获取放在页面/组合式函数里组件接收option对象通过watch自动setOption。这样图表的通用性最高也方便单元测试。5. 打包构建与部署上线5.1 打包配置正确设置base与publicPath大屏项目打包后经常遇到“页面白屏”“资源404”的问题十有八九是路径配置不对。默认情况下Vite打包后的资源路径是绝对路径/assets/xxx但如果你部署在子路径比如http://ip:8080/screen/就必须修改baseexport default defineConfig({ base: ./, // 关键使用相对路径 // ... })设置为./后打包产物里引用的资源路径会变为相对路径在Nginx或Tomcat的任意子目录下都能正常打开。这里注意一个细节如果项目里用了createWebHistory路由模式刷新某个子路由时会出现404需要后端做try_files回退或者干脆切换为createWebHashHistory模式。大屏项目通常不强求URL美观用hash模式最省心。5.2 打包后布局异常常见原因与排查思路热词里有个高频问题叫“vue 打包后布局异常”这在部署的场景下值得单独讲。我遇到过几次总结下来原因通常是这几类样式文件加载顺序错乱项目里使用了大量的position: absolute和z-index层级打包后样式合并加载顺序变化导致元素堆叠顺序不一致。这种情况建议提升布局组件的层级稳定性尽量使用BEM命名避免深层嵌套选择器并把base.css提到入口文件最前面引入。图片路径错误导致背景图缺失打包后背景图404视觉表现是“有些区域空白”。排查时打开浏览器Network面板看资源请求路径是否正常。如果CSS里使用了相对路径引用图片注意在Vite配置里设置base: ./。图表容器尺寸为0打包后图表空白但控制台无报错很多时候是因为容器在图表初始化时display: none或者高度为0。尤其大屏项目多屏切换或iframe嵌入时比较容易触发。解决办法是在容器尺寸变化后主动调用图表实例的resize()或者把初始化时机放到nextTick和onMounted后。字体加载延迟影响布局大屏常用特殊字体数字字体、艺术字体打包后字体文件体积大加载慢字体切换瞬间可能造成文字溢出。建议先用系统字体占位字体加载完成后再切换font-display: swap。5.3 Nginx部署配置要点大屏项目部署到Nginx时我的推荐配置如下server { listen 80; server_name your-domain.com; root /data/www/screen/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /ws/ { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } }几个值得注意的点try_files保障了前端路由刷新不404。/api/接口转发和/ws/WebSocket转发一定要分开配置WebSocket需要额外处理Upgrade和Connection头否则前端WebSocket连接一直失败。大屏项目通常放在公网访问建议在Nginx层开启Gzip对ECharts这种JS大文件效果非常明显。开启方式是在nginx.conf里加上gzip on; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss image/svgxml; gzip_min_length 1k;6. 常见问题排查与避坑实录大屏项目踩坑记录整理成速查表方便你按图索骥问题现象原因分析解决方案部署后页面空白base路径配置错误资源404检查Network请求路径将base改为./或正确绝对路径打包后布局错乱样式加载顺序变化或图片路径错误按章节5.2逐项排查优先看Network和Computed样式图表点击无响应使用了transform整体缩放未处理scale和坐标系映射要么改用rem方案要么手动修正event.offsetX/offsetY定时器数据重复叠加组件销毁时未清除定时器或WebSocket未关闭在onUnmounted里统一清理定时器和WS连接ECharts内存泄漏频繁init/dispose或数据更新未释放旧实例复用图表实例单页使用全局管理器跟踪所有实例WebSocket频繁断开代理未配置Upgrade头或心跳过短在Nginx配置proxy_set_header Upgrade $http_upgrade;m3u8视频一直黑屏CORS跨域或HLS时间戳异常检查响应头是否带CORS换用hls.js低延迟模式数据大屏在低配工控机特别卡动画过多、图表实例未复用、无防抖关闭图表动画、统一调度数据更新、加requestAnimationFrame节流路由刷新404使用history模式但后端未做回退切hash模式或后端配置try_files多图表resize抖动每个图表单独监听resize且未节流统一一个调度器用防抖批量调用所有图表resize有一些感受想重点强调先看图表的容器尺寸再谈图表不显示。几乎所有“图表空白”的问题90%都是容器宽高异常与ECharts本身无关。定时器和WebSocket的清理动作比初始化动作更值得投入精力。大屏页面常在展厅或指挥中心挂着内存泄漏会随着时间越来越严重表现就是页面越来越卡、最终白屏。数据脱敏和后端权限要在联调阶段就约好。大屏是给领导或客户看的接口返回的敏感字段如果没有在服务端过滤前端展示就不是一个小问题。7. 性能优化与交付经验7.1 渲染性能控制图表数量和更新频率大屏页面不建议无限堆图表。经验值是一屏控制在10个图表以内如果确实业务需要很多模块就通过分页、Tab切换或滚动来组织。数据更新频率同样要有上限单项数据最低轮询间隔不要低于3秒否则接口压力大、前端也一直在渲染整体体验反而差。数据更新时也千万不要整个页面级状态变化。组件只更新自己负责的数据片段比如watch( () props.latestAlarm, (val) { chartRef.value?.setOption({ series: [{ data: val }] }) } )这种局部更新比整页刷新或者大组件重渲染高效得多。7.2 资源加载优化路由懒加载与CDN分割大屏项目首屏加载要快最好的手段是路由懒加载也就是上面路由配置中使用的动态import写法。这样一来首屏只需要加载当前大屏页面相关的代码而不是一次性全部加载。对于体积特别大的库比如ECharts、hls.js可以考虑在index.html里通过CDN引入并在vite.config.ts的build.rollupOptions.external里排除这样能显著减少打包体积但要保证CDN可用并锁版本。7.3 交付阶段的检查清单每次大屏项目交付前我都会按照下面这份清单走一遍能避免大多数翻车现场多分辨率真机自测至少验证1080P、2K两种分辨率下布局正常。断网/弱网测试接口超时有没有兜底loading、图表有没有空数据占位。长时间挂机测试运行4-8小时观察内存是否持续增长、WS是否稳定。数据重置机制验证切日切周后所有图表数据是否正确刷新。屏幕休眠唤醒测试长时间不操作后是否一切正常唤醒后定时器是否还在跑。大屏展示模式确认全屏化F11时布局和无操作自动刷新是否正常。大屏开发这件事技术本身不神秘真正拉开差距的是对细节的把控。有人做的项目稳定跑一年有人做的项目上线第一天就出幺蛾子差别往往不在框架选型而在适配方案、数据通道、组件封装和部署配置这些基础功夫上。希望这篇全流程拆解能帮你少踩几个坑。最后再分享一个经验大屏项目代码不一定多复杂但调试环境一定要搭好开发模式、联调模式、生产模式三套环境变量务必事先配好后期会省下大量时间。

Vue3 + Vite + ECharts 大屏项目全流程实战指南

相关推荐

基于STM32两路步进电机控制：定时器PWM与梯形加减速实现双轴同步

条形码生成工具怎么选？

微信小程序LBS实战：从定位到附近美食POI检索与排序

更多资讯

在 Linux 上使用 rbenv 安装与管理 Ruby：完整安装指南

Rekor 可插拔类型（Pluggable Types）机制深度解析：透明日志条目 Schema 插件体系与 BuildKit 中的落地实践

长沙市POI数据处理实战：从7z解压到DEM叠加分析

C++实现结构光激光中心线亚像素提取

Carbon Web Components 的 `cds-code-snippet` 渲染原理与快照测试深度解析

mlx-audio 中的 Dramabox 语音合成：基于 LTX DiT + Gemma 编码器的 48 kHz 立体声 TTS 与参考音频克隆实现

今日更新

基于MATLAB的CRI显色指数计算：从SPD光谱到Ra的完整流程

JSP+Servlet+MySQL博客系统源码部署与优化全攻略

蜂窝调度算法 MATLAB 实现：比例公平、轮询与最大 C/I 对比

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？