企业官网建设流程全解析

1. 大前端到底在讲什么：从“前端”到“大”的边界扩张

“大前端”这个词，这几年被提得特别多，但真正能把它讲清楚的文章并不多。很多人第一次听到这个词，脑子里浮现的是“前端是不是又卷出新花样了”。其实不是。大前端不是某个具体框架，也不是某一门新技术，它描述的是一种工程边界的变化——前端能做的事情，从浏览器里的页面，扩展到了移动端、桌面端、服务端渲染、跨端小程序、甚至部分后端能力。

我最早接触这个概念是在做一个多端项目的时候。当时的需求是：同一套业务逻辑，要同时跑在 Web、微信小程序、以及一个内部的桌面客户端上。如果按传统思路，三个端三套代码，维护成本直接爆炸。后来团队决定用一套技术栈去覆盖，这时候我才真正理解“大前端”不是噱头，而是被业务逼出来的工程选择。

大前端的核心特征可以归纳为三点：

• 技术栈统一：JavaScript/TypeScript 成为通用语言，React、Vue、Angular 等框架在不同端复用。
• 工程链路拉长：从代码编写、构建、打包、部署，到性能监控、错误追踪，前端要管的事情越来越多。
• 职责边界模糊：前端开始涉足 BFF（Backend for Frontend）、SSR（服务端渲染）、甚至部分 DevOps 工作。

所以，当你看到“大前端”这个词时，不要把它理解成“前端变大”这么简单。它更像是一种角色升级：前端工程师不再只是切图、调样式，而是要具备跨端思维、工程化思维、甚至一定的服务端思维。

提示：如果你现在还在只写页面、不关心构建和部署，那大前端对你来说可能还只是一个概念。但如果你已经开始接触多端复用、Node 中间层、或者微前端，那你其实已经在大前端的路上了。

2. 大前端的技术版图：哪些技术真正撑起了这个体系

要讲清楚大前端，光说概念没用，得看它背后到底有哪些技术在做支撑。我把目前主流的大前端技术版图拆成四个层面，每个层面都有对应的核心技术和典型场景。

2.1 跨端框架：一套代码跑多端

跨端是大前端最直观的体现。目前主流方案分两类：

我实际用过 Taro 和 Uni-app 做小程序矩阵，最大的感受是：跨端不是“写一次就万事大吉”，而是“写一次，然后针对每个端做适配”。比如小程序的登录流程和 H5 完全不同，支付逻辑也有差异。所以跨端框架解决的是代码复用率问题，不是零适配问题。

2.2 微前端：让大型应用可以拆分

当项目大到一定程度，单体前端会变得难以维护。微前端就是把这个大应用拆成多个独立的小应用，每个小应用可以独立开发、独立部署。

主流方案有：

• single-spa：最早的微前端框架，灵活但配置复杂。
• qiankun：基于 single-spa 封装，国内用得最多。
• Module Federation：Webpack 5 原生支持，适合模块共享。

我踩过的一个坑是：微前端不是银弹。如果团队规模不大、项目复杂度不高，强行上微前端只会增加沟通成本和构建复杂度。微前端适合的是“多个团队维护同一个大应用”的场景，不是“一个团队想炫技”的场景。

2.3 BFF 与 SSR：前端开始碰服务端

BFF（Backend for Frontend）是前端向服务端延伸的典型表现。简单说，就是在后端 API 和前端页面之间加一层 Node 服务，专门为前端做数据聚合、裁剪和格式化。

SSR（服务端渲染）则是另一个方向。Next.js、Nuxt.js 这些框架让前端可以在服务端渲染页面，解决首屏性能和 SEO 问题。

我做过一个 SSR 项目，最大的体会是：SSR 不是性能优化的万能药。它确实能提升首屏速度，但也会带来服务端压力、缓存复杂度、以及调试难度。如果只是内部管理系统，完全没必要上 SSR。

2.4 工程化与 DevOps：前端也要管部署

大前端时代，前端工程师要管的事情远不止写代码。构建工具从 Webpack 到 Vite，包管理从 npm 到 pnpm，CI/CD 从 Jenkins 到 GitHub Actions，这些都在前端的工作范围内。

我现在的习惯是：每个项目都必须有完整的构建和部署脚本，不能依赖手动操作。因为一旦涉及多端发布，手动操作几乎必然出错。

3. Vue3 + Element Plus 大屏自适应方案：从设计稿到真实屏幕

前面讲的是大前端的宏观版图，现在落到一个非常具体的场景：Vue3 + Element Plus 做数据大屏，怎么让页面在不同分辨率下都能正常显示。这个问题看起来简单，但实际做起来坑非常多。

3.1 为什么大屏自适应这么难

大屏项目和普通后台项目最大的区别是：设计稿通常是一个固定分辨率，比如 1920x1080，但实际投放的屏幕可能是 4K、2K、甚至拼接屏。如果直接用百分比布局，元素会变形；如果用固定像素，小屏上会溢出。

常见的自适应方案有三种：

1. rem 方案：根据屏幕宽度动态设置根字体大小，所有尺寸用 rem。
2. scale 缩放方案：把整个页面按设计稿尺寸渲染，然后整体缩放。
3. vw/vh 方案：直接用视口单位，配合媒体查询做断点。

我实际对比过这三种方案，结论是：大屏项目首选 scale 缩放方案，因为大屏通常是固定比例展示，缩放不会导致布局错乱。而 rem 和 vw 更适合需要响应式重排的页面。

3.2 scale 缩放方案的具体实现

核心思路是：设计稿按 1920x1080 做，页面加载时计算屏幕宽高与设计稿的比例，然后通过 CSS transform 缩放整个容器。

// useScreenScale.js import { ref, onMounted, onUnmounted } from 'vue' export function useScreenScale(designWidth = 1920, designHeight = 1080) { const scale = ref(1) const wrapperStyle = ref({}) const calcScale = () => { const screenWidth = window.innerWidth const screenHeight = window.innerHeight const scaleX = screenWidth / designWidth const scaleY = screenHeight / designHeight scale.value = Math.min(scaleX, scaleY) wrapperStyle.value = { transform: `scale(${scale.value}) translate(-50%, -50%)`, transformOrigin: 'top left', position: 'absolute', left: '50%', top: '50%', width: `${designWidth}px`, height: `${designHeight}px` } } onMounted(() => { calcScale() window.addEventListener('resize', calcScale) }) onUnmounted(() => { window.removeEventListener('resize', calcScale) }) return { scale, wrapperStyle } }

然后在页面中使用：

<template> <div class="screen-wrapper" :style="wrapperStyle"> <div class="screen-content"> <!-- 你的大屏内容 --> </div> </div> </template> <script setup> import { useScreenScale } from './useScreenScale' const { wrapperStyle } = useScreenScale(1920, 1080) </script>

这个方案的好处是：设计稿怎么写，代码就怎么写，不需要换算单位。缺点是缩放后字体可能会模糊，尤其是小字体。解决办法是尽量用大字号，或者对关键文字单独做处理。

3.3 Element Plus 在大屏项目中的适配问题

Element Plus 默认是为后台管理系统设计的，组件尺寸偏小，直接放到大屏上会显得很局促。我通常做两件事：

• 全局调整组件尺寸：通过 ConfigProvider 设置 size 为 large。
• 覆盖部分组件样式：比如表格的行高、按钮的内边距、弹窗的宽度。

// main.js import { createApp } from 'vue' import ElementPlus from 'element-plus' import 'element-plus/dist/index.css' import App from './App.vue' const app = createApp(App) app.use(ElementPlus, { size: 'large' }) app.mount('#app')

另外，大屏项目通常不需要 Element Plus 的响应式栅格，因为整个页面是固定比例缩放的。所以我会把 el-row、el-col 的断点逻辑关掉，直接用 flex 布局。

注意：scale 缩放方案下，鼠标事件的位置也会被缩放。如果你有拖拽、点击等交互，需要把鼠标坐标除以 scale 值，否则定位会偏移。这个坑我在第一个大屏项目里踩过，排查了半天才发现是缩放导致的。

4. 前端页面大屏布局探针：它到底是什么，怎么用

“大屏布局探针”这个词听起来很专业，其实它解决的是一个非常实际的问题：在大屏项目开发阶段，怎么快速定位布局问题。

4.1 探针的本质：可视化调试工具

探针本质上是一段注入到页面中的脚本，它会在页面上叠加一层可视化标记，显示每个元素的边界、尺寸、层级关系。类似浏览器 DevTools 里的“检查元素”，但探针是常驻的，可以实时看到布局变化。

我常用两种探针：

• 边界探针：给所有元素加一个半透明边框，快速看出哪些元素溢出、哪些元素重叠。
• 网格探针：在页面上叠加一层网格线，帮助对齐元素。

// layoutProbe.js export function enableLayoutProbe(options = {}) { const { color = 'rgba(255, 0, 0, 0.3)', grid = false, gridSize = 50 } = options const style = document.createElement('style') style.id = 'layout-probe-style' style.innerHTML = ` * { outline: 1px solid ${color} !important; } ${grid ? ` body::after { content: ''; position: fixed; top: 0; left: 0; width: 100%; height: 100%; pointer-events: none; background-image: linear-gradient(to right, rgba(0,0,0,0.1) 1px, transparent 1px), linear-gradient(to bottom, rgba(0,0,0,0.1) 1px, transparent 1px); background-size: ${gridSize}px ${gridSize}px; z-index: 99999; } ` : ''} ` document.head.appendChild(style) } export function disableLayoutProbe() { const style = document.getElementById('layout-probe-style') if (style) style.remove() }

在开发环境中，我会在路由切换时自动开启探针，生产环境则完全移除。

4.2 探针在大屏项目中的实际价值

大屏项目和普通页面最大的不同是：它通常是在一个非标准分辨率下开发的，但要在多个标准分辨率下展示。比如你在 1920x1080 的显示器上开发，但实际投放可能是 3840x2160 的 4K 屏。

这时候探针的作用就体现出来了：

• 快速发现溢出：大屏上经常有绝对定位的元素，探针能一眼看出哪些元素超出了设计稿范围。
• 检查层级关系：大屏上图表、文字、装饰元素经常重叠，探针能帮你确认 z-index 是否正确。
• 验证缩放效果：开启探针后，缩放整个页面，看边框是否跟着缩放，能验证 scale 方案是否生效。

我现在的习惯是：大屏项目开发阶段，探针常开。等到布局稳定后再关掉，做最终视觉验收。

4.3 探针的进阶用法：结合 Vue 指令

如果你用 Vue3，可以把探针封装成一个自定义指令，按需开启。

// vProbe.js export const vProbe = { mounted(el, binding) { if (binding.value) { el.style.outline = '1px solid rgba(255, 0, 0, 0.3)' } }, updated(el, binding) { el.style.outline = binding.value ? '1px solid rgba(255, 0, 0, 0.3)' : 'none' } }

然后在组件中：

<template> <div v-probe="isDev"> <!-- 内容 --> </div> </template>

这样你可以精确控制哪些元素需要探针，而不是全局开启。

提示：探针不要在生产环境开启，否则用户会看到一堆红色边框。建议通过环境变量控制，比如import.meta.env.DEV。

5. 大前端工程师的成长路径：从写页面到管工程

聊完具体技术，回到一个更根本的问题：大前端时代，前端工程师应该怎么成长。我带了几年团队，也面试过不少人，发现一个普遍现象：很多人工作三五年，技能还停留在“会用框架写页面”的阶段。这在过去可能够用，但在大前端时代，竞争力会越来越弱。

5.1 第一阶段：把基础打牢

不管技术怎么变，基础永远是基础。我指的不仅是 HTML、CSS、JavaScript，还包括：

• 浏览器工作原理：渲染流程、事件循环、内存管理。
• 网络基础：HTTP 缓存、跨域、WebSocket。
• 工程基础：模块化、构建工具、包管理。

这些内容看起来枯燥，但决定了你能走多远。我见过太多人因为不懂事件循环，在面试中卡壳；因为不懂 HTTP 缓存，在性能优化时无从下手。

5.2 第二阶段：建立工程思维

工程思维的核心是：把代码当成一个需要长期维护的系统，而不是一次性的任务。

具体表现：

• 写代码时考虑可测试性、可扩展性。
• 做技术选型时考虑团队成本、维护成本。
• 上线前考虑监控、回滚、灰度。

我现在的习惯是：每做一个新项目，先写技术方案文档，把选型理由、架构设计、风险点都写清楚。这个过程逼着我思考，也方便后续复盘。

5.3 第三阶段：拓展边界

大前端的“大”，最终体现在边界拓展上。你可以选择的方向包括：

• 向服务端延伸：学 Node.js、Nest.js，做 BFF 层。
• 向移动端延伸：学 React Native、Flutter，做跨端开发。
• 向工程化延伸：学 CI/CD、Docker、K8s，做前端基建。
• 向可视化延伸：学 WebGL、Three.js，做数据可视化。

我个人的选择是工程化 + 可视化，因为这两个方向和我做的大屏项目高度相关。但每个人的路径不同，关键是找到自己的兴趣和业务需求的交集。

5.4 一个容易被忽略的能力：技术表达

最后说一个很多人忽略的点：技术表达。大前端工程师经常需要跨团队协作，能不能把技术方案讲清楚，直接影响项目推进效率。

我见过技术很强但不善表达的工程师，方案很好但推不动。也见过技术一般但表达清晰的工程师，反而能拿到更多资源。所以，写文档、做分享、画架构图，这些能力值得刻意练习。

6. 大屏项目实战中的几个真实坑

前面讲了很多原理和方法，最后分享几个我在大屏项目中真实踩过的坑。这些坑在官方文档里通常不会写，但实际做项目时几乎一定会遇到。

6.1 字体缩放后的模糊问题

scale 缩放方案下，如果缩放比例不是整数，字体边缘会模糊。尤其是小字号，模糊感非常明显。

解决办法有两个：

• 尽量用大字号：大屏项目本身就应该用大字号，14px 以下的字体在大屏上根本看不清。
• 对关键文字用 SVG 或 Canvas 渲染：这样缩放时不会失真。

我现在的做法是：正文最小 18px，标题 24px 起步。这样即使缩放比例是 0.8，字体依然清晰。

6.2 图表库的适配问题

ECharts 是大屏项目最常用的图表库，但它默认的字体大小、边距都是按普通页面设计的。直接放到大屏上，图表会显得很小。

我的做法是：封装一个 ECharts 组件，统一设置字体大小、网格边距、颜色主题。这样每个图表只需要传数据，不用重复配置样式。

// useECharts.js import * as echarts from 'echarts' export function useECharts(domRef, options) { let chart = null const init = () => { if (!domRef.value) return chart = echarts.init(domRef.value) chart.setOption({ textStyle: { fontSize: 18 }, grid: { top: 60, right: 40, bottom: 60, left: 60 }, ...options }) } const resize = () => { chart?.resize() } return { init, resize, getChart: () => chart } }

6.3 定时刷新导致的内存泄漏

大屏项目通常需要定时刷新数据，比如每 30 秒请求一次接口。如果不在组件卸载时清除定时器，就会导致内存泄漏。

我踩过一次坑：页面切换了十几次后，浏览器变得非常卡。排查后发现是定时器没有清除，每次切换都新增一个定时器。

解决办法很简单：在 onUnmounted 中清除所有定时器。

import { onMounted, onUnmounted } from 'vue' let timer = null onMounted(() => { timer = setInterval(fetchData, 30000) }) onUnmounted(() => { if (timer) { clearInterval(timer) timer = null } })

这个坑看起来很低级，但实际项目中非常常见。尤其是多人协作时，别人写的组件你不一定清楚里面有没有定时器。

6.4 大屏的首次加载性能

大屏项目通常包含大量图表和动画，首次加载可能很慢。如果投放现场网络不好，会出现白屏。

我的优化策略：

• 路由懒加载：把大屏页面拆成多个 chunk，按需加载。
• 图表延迟初始化：首屏只加载关键图表，其他图表等页面稳定后再初始化。
• 骨架屏：在数据加载完成前显示一个简单的骨架屏，避免白屏。

这些优化看起来简单，但效果非常明显。我做过对比，优化后首屏时间从 4 秒降到了 1.5 秒。

7. 我对大前端的一点个人看法

写了这么多，最后说点个人感受。大前端这个概念，有人觉得是炒作，有人觉得是趋势。我的看法是：它描述的是一种事实，而不是一种主张。

事实是：前端能做的事情确实变多了，前端工程师需要掌握的技能确实变广了。你可以选择只做页面，但你会发现，只做页面的岗位越来越少，要求越来越低。你也可以选择拓展边界，虽然累一点，但路会越走越宽。

我自己的路径是从 Vue 页面开发，到工程化，再到大屏可视化。每一步都是被业务逼出来的，但回头看，每一步都值得。如果你现在正处在某个瓶颈期，我的建议是：不要等公司给你机会，自己找一个小项目练手。比如用 Vue3 + Element Plus 做一个大屏，把自适应、探针、性能优化都走一遍。做完之后，你对大前端的理解会完全不一样。

这个内容后续还可以这样扩展：比如微前端在大屏项目中的落地实践，或者用 WebGL 做更复杂的大屏可视化效果。如果你对这些方向感兴趣，可以自己先查资料试试，踩坑的过程本身就是最好的学习。