企业官网建设流程全解析

简介：这是一份基于Vue.js实现PC端与移动端自适应的完整项目源码，面向需要掌握跨设备响应式开发的前端工程师。项目以adaptiveDifferentiation-master为主线，覆盖Flexbox弹性布局、媒体查询、Vue Router动态路由、Vuex状态管理、生命周期设备检测、自定义指令及性能优化等实践要点，并附有基础配置与说明文档，可直接作为中后台或H5自适应方案参考。压缩包共35个文件，以Vue组件和JS逻辑为主，另含HTML入口、PNG图标、Markdown说明及JSON配置，整体仅124KB，结构清晰便于快速阅读。已有423人学习，尤其适合对照源码学习PC与移动端差异化路由分流、媒体查询断点设置、Vuex按设备存储状态等具体写法，迁移到自身项目时可以减少踩坑。 站在十月末的时间点回看这个项目，真是感慨颇多。这个“基于vue项目下PC端和移动端实现的自适应.zip”乍一看只是个普通打包文件，但我拿到手拆开之后，发现它几乎把做一个全适配前端项目该碰到的坑都踩了一遍。如果你现在正准备用vue做一个需要同时兼容PC端和移动端的项目，或者你只是想知道“自适应到底怎么在vue项目里落地”，这篇文章应该能帮你少走不少弯路。

先说清楚这个zip里到底是什么。它不是那种写死两套页面的双端分离项目，也不是开箱即用的框架模板，而是一套把PC端后台、移动端H5页面统一在一套vue代码体系下、通过样式和布局层面的自适应策略来兼容不同屏幕的完整实践。换句话说，它的核心解决的是“同一套vue代码，怎么在大屏幕和小屏幕上都不难看、不乱掉”的问题。这个需求在真实项目中太常见了——你可能有一个后台管理界面要跑在公司的大屏上，又要保证客户拿着手机也能正常操作；你也可能有一个H5活动页，需要在iPad和安卓小屏上都保持视觉一致。这就是自适应要干的事。

下面我就把这套方案从选型到落地、再到排查问题的全过程拆开讲，里面包含了我自己试验过的参数、踩过坑之后总结出来的经验，纯个人实操分享，不是纸上谈兵。

1. 正式动手前：先想清楚你要的是自适应还是响应式

很多人在做vue项目自适应时，第一个分岔路口就搞错了方向。自适应和响应式在工程上其实是两套思路，虽然它们最后呈现的效果有点接近，但实现路径和适用场景差了很远。

1.1 需求梳理的两个关键维度

拆这个zip之前，我先把自己的需求问清楚了两件事：

• 屏幕跨度多大？如果只是PC端从1366px到1920px的跨度，那其实用传统的固定宽度+栅格系统就能解决，根本不复杂；但如果要兼容到375px的手机端，这就不是简单栅格能搞定的了。
• 布局结构是否一致？如果PC端是左侧菜单+顶部栏+内容区，而移动端需要改成底部Tab+全屏卡片，那这属于“响应式重构”，不是单纯缩放的“自适应”；如果两端结构一致只是尺寸不同，那才适合用viewport、rem这类等比缩放的方案。

1.2 能用技术方案解决的事，别用加班解决

我看到不少人拿到这种需求，第一反应是“那就写两套页面呗，encapsulate到不同路由下”。但你要考虑维护成本。两套页面意味着两套逻辑同步改，后端接口一变化，前端两处代码都要动，bug率直接翻倍。

所以在工期有限的情况下，优先考虑的是“怎么用一套代码 + 合理的适配策略”覆盖两端。实在有无法兼容的局部模块，再单独做移动端组件，而不是整体写两套。这个原则也是这个zip项目最初定下的基调。

2. 自适应方案的横向对比：vue项目里到底该怎么选

市面上的自适应方案其实就那几种，抛开那些花里胡哨的包装，核心方法论没几个。我把自己真实用过的方案做一个横向对比，各有适用的场景，也说清楚我用在哪个环节。

2.1 rem + flexible方案：经典但需要细节控制

rem方案的核心逻辑是：把html根字号设置为屏幕宽度的一个比例值，然后页面里所有尺寸都用rem来写，这样屏幕一变，所有带rem单位的属性都跟着等比缩放。

过去常用lib-flexible这个库来动态设置根字号，它会把屏幕宽度分成10份，1rem等于屏幕宽度的1/10。但现在lib-flexible已经很少维护了，而且它默认把视觉稿统一按750px来算，这对纯移动端项目没毛病，但如果同时要做PC端，根字号上限得自己卡住，否则PC宽屏下字会大到离谱。

// 一个极简的rem设置逻辑，不引入任何库 function setRem() { const baseSize = 16; // 基准字号，以设计稿宽度为 375 时设置 16px const scale = document.documentElement.clientWidth / 375; document.documentElement.style.fontSize = baseSize * Math.min(scale, 2.5) + 'px'; } setRem(); window.addEventListener('resize', setRem);

注意我加了Math.min(scale, 2.5)，这个上限非常关键。不加的话，PC端1920px的屏幕上，1rem会变成大约82px，整个页面都会显得很空旷、很傻。加上上限之后，PC端最大字号被锁住，再配合容器max-width控制，体验会好很多。

2.2 vw/vh方案：更直接但精度问题要留意

vw/vh方案是把视口宽度/高度直接作为单位，1vw等于屏宽的1%，这样连根字号的js都不用写了。配合PostCSS插件，比如postcss-px-to-viewport，可以直接在编译阶段把px转成vw，开发时依然按设计稿写px，发布后自动转换，非常省心。

不过它有个小坑：当宽度很小时，比如屏幕只有320px，1vw就是3.2px，如果border-left是1px转成0.3125vw这种小数，部分浏览器在缩放时会产生渲染模糊。如果项目对清晰度要求高，比如有很多细边框、小图标，需要用media query对极窄屏做特殊处理。

2.3 媒体查询 + 断点：永远不能完全丢掉的一环

我一直认为，不管用rem还是vw，媒体查询都不能完全省略。因为自适应解决的只是“等比缩放”，但有些元素在屏幕太窄时就不适合“等比例缩小”了，而应该“换个呈现方式”。比如表格，手机屏上再缩小也放不下7列数据，这时候要么横向滚动，要么换成卡片式渲染；再比如导航栏，PC端是横排链接，手机上可能就得收起成汉堡菜单。这种结构性变化，必须靠媒体查询断点来触发。

所以我的最终结论是：非纯移动端项目，优先用vw方案做尺寸换算，同时保留媒体查询处理布局断点；纯移动端H5，可以用rem方案或者干脆vw一条路走到黑。把这个策略定下来之后再动手，后面会顺畅很多。

3. 在vue项目里落地：一步步配置完整个自适应体系

方案定了，接下来就看你具体怎么把一套其实并不复杂的配置搭进vue项目里。这里我把zip里用到的配置项和步骤写成可以直接照抄的清单。

3.1 用postcss-px-to-viewport还是postcss-pxtorem？

这个选择会直接影响你的开发习惯。在vue项目里，样式处理通常交给PostCSS来做。如果你想走vw路线，用postcss-px-to-viewport；如果你想走rem路线，用postcss-pxtorem。两者不能混用，否则样式会乱。

我这次用的是vw方案，配置如下：

// postcss.config.js module.exports = { plugins: { 'postcss-px-to-viewport': { viewportWidth: 375, // 设计稿宽度，依据你的实际设计稿来 unitPrecision: 5, // 转换后的vw精度，小数点后保留位数 viewportUnit: 'vw', selectorBlackList: ['.ignore', '.hairlines'], // 这两个类名下不转换 minPixelValue: 1, // 小于等于1px的不转换 mediaQuery: false } } }

viewportWidth这个参数非常关键。如果你的设计稿是750px（常见的移动端设计稿宽度），那这里就要填750；如果是按375px设计的，就填375。填错的话，所有尺寸都会大一倍。

还要提一句selectorBlackList，这是我很喜欢的一个配置。有的场景下我需要固定1px的物理像素边框，不想让它被放大缩小，就把类名加进去，插件会直接跳过。

3.2 PC端和移动端并存时的特殊处理

如果你只是做移动端H5，上面这个配置就完事了。但咱们这个项目的核心难点在于“PC端+移动端并存”。当PC端也用同一套vw换算时，一个很现实的问题出现了：375px设计稿中的字号，在1920px屏幕上会被放大到约5倍，空间感完全不一样。

应对方式其实有两个：

• 给PC端和移动端分别准备不同的postcss配置，打包时根据环境变量切换。这种方式适合两端样式差异较大的场景。
• 还是用同一套vw逻辑，但给PC端单独写一个容器宽度上限，比如最大宽度1440px，然后居中显示。这适合后台管理系统这种“内容居中排版即可”的场景。

我这次用的是第二种，成本低，而且视觉上不至于因屏幕过大而太松散。

3.3 开发时的编写规范

配置完之后，开发时有一个新习惯要养起来：间距和字号用px原值写，布局用flex/grid的百分比或auto。这句话听着像废话，但实际操作中我发现很多新人会把间距也写成vw，导致不同屏幕上间距忽大忽小，观感很累。间距本身就应该是一个相对固定的节奏，屏幕变大时它也要变大，但不要“成倍放大”，所以用px写原值、交给插件转vw反而最合理。

4. 组件库拿过来怎么调教：第三方UI的自适应问题

在vue项目里，几乎不可能不引入组件库。后台管理项目用Element Plus或Ant Design Vue居多，移动端H5则用Vant。但这些组件库的样式基准是基于它们自己的设计稿写的，引入之后如果不管，组件尺寸和你的自适应体系会打架。

4.1 组件库尺寸的全局缩放

以Vant为例，它的默认设计稿宽度是375px，而你的设计稿可能也是375px，理论上不会出大问题。但如果你的viewport配置里的viewportWidth填了750，那Vant的样式也会被转换成基于750的vw，结果就变成所有组件缩小了一半。

这种情况下有两个解决办法：

• 插件里配置inlineStyle: false，不让组件库的行内样式被转换。
• 用exclude或selectorBlackList把Vant相关样式排除掉，然后自己写一套适配样式覆盖上去。

如果你是PC端用Element Plus、移动端用Vant这种混合场景，更省事的方式是——组件库尺寸不转vw，全部保持px原值，只在你的业务组件里启用vw转换。因为组件库的自适应能力有限，强行缩放反而容易出现模糊、错位的问题，不如让它在两端都保持固定px宽度，用media query在窄屏时调整外层布局。

4.2 复杂组件的高度适配案例

项目里我印象最深的是一个数据表格。PC端表格要展示8列数据，字体、行高、列宽都需要足够的空间；但同一个表格在手机上又需要依旧可用。我的做法是：外层div上用媒体查询断点，小于768px时，表格外层加一个横向滚动容器，表格本身保留最小宽度。

.table-wrapper { width: 100%; overflow-x: auto; } .table-wrapper table { min-width: 900px; /* 小于768px时维持表结构可读 */ } @media (max-width: 768px) { .table-wrapper { -webkit-overflow-scrolling: touch; overflow-x: auto; } }

这样既不需要为了移动端单独做一套表格组件，又保证了数据在多端的可读性。这种做法是很实用的工程折中，我觉得可以算这类自适应项目的通用思路之一。

5. 自适应做完了，调试却花了两天：这些坑值得单独记录

配置都配好、代码也写完了，是不是就万事大吉？完全不是。我在实际调试过程中被几个问题反复折腾，最夸张的一次花了整整两个晚上才定位到原因。现在把这些坑一一列出来，你们如果再遇到，就直接照方抓药。

5.1 1px边框变粗或消失的问题

当vw方案把1px转成0.267vw之后，在retina屏上因为devicePixelRatio的存在，可能会出现边框时粗时细的情况。我的解决思路是不要依赖PostCSS自动转边框，而是用transform: scale(0.5)的方式模拟细边框，或者把需要精细边框的元素加入selectorBlackList，让它保持物理像素1px。

5.2 iframe内页面不自适应

项目里嵌入了一个报表页面，通过iframe加载。问题在于，iframe里的页面是另一个独立项目，它没有继承外部项目的自适应逻辑。父页面无论怎么缩放，iframe里的内容始终保持固定宽度，看起来非常割裂。

这个问题最彻底的解决方式是让后端把iframe内容改造成可适配的；如果控制不了，就得在iframe外层用一个固定高度容器，内部通过transform缩放来匹配父页面的宽度。这个方法有性能损耗，但应急可用。

5.3 输入框聚焦时页面被放大

在iOS Safari上，如果输入框的字号小于16px，点击输入时浏览器会自动放大页面，这会导致整个自适应布局瞬间错乱。这个坑很经典，很多人都会遇到，但其实只要保证输入框字体不小于16px就能解决。

input, textarea, select { font-size: 16px; }

5.4 常见问题排查清单

我把这个项目里踩过的坑和对应的排查顺序整理成一个速查表，收藏起来会比翻源码高效得多。

排查时我习惯先在浏览器DevTools里点开计算样式面板，看具体元素最终的font-size是多少px。如果换算结果明显不对，九成是postcss配置的viewportWidth或根字号计算函数出了问题。

5.5 性能层面的自查

自适应方案本身不会带来特别严重的性能问题，但vw方案导致页面重新计算样式是不可避免的，尤其是在窗口resize时。我给项目做了一次性能自查，发现真正拖慢渲染的其实是大量用vw写的box-shadow和filter样式——这些样式在resize过程中会不断重绘。优化方式就是把这些装饰性样式放到一个单独类里，只在非resize状态下通过class开关控制展示，或者直接换成用transform模拟阴影效果。

6. 两个实战片段：同一套代码在不同终端下的最终效果

光说配置和坑可能还比较抽象，我直接放两个实际运行片段，大家可以感受一下落地效果。

6.1 PC端后台首页的适配表现

这是一套带左侧菜单的后台管理界面。左侧菜单固定宽度220px，右侧内容区宽度用calc(100% - 220px)，中间的卡片栅格用flex布局，每一行默认四列，当浏览器窗口缩小到1280px以下时，通过媒体查询改为两列展示。

整个页面在大屏下非常舒展，字体也不会因为屏幕变大而失态；缩小到平板尺寸时，卡片自动重排； 再进一步到手机尺寸（假设你坚持用同一个路由），左侧菜单会缩成图标+抽屉展开的方式。

6.2 移动端H5详情页的等比缩放

移动端页面更像传统H5活动页，上下排列的封面图、标题、价格区、按钮区。这里所有间距都是以vw为单位，所以不同手机宽度下整个页面的视觉比例基本一致，只有极小屏幕或者带刘海屏的特殊机型需要单独调一下安全区域。

在iPhone 12和安卓千元机上，页面比例几乎看不出差别，这就是等比缩放方案的好处。 如果你做的是电商详情页或者内容展示页，这种一致性能让设计还原度大幅提升。

7. 回到标题：这个zip项目到底帮你解决了什么

这个项目实际上是一整套vue下PC端+移动端自适应方案的完整落地方案。它包含了设计稿的选型策略、PostCSS配置细节、组件库的调教方案，以及一长串我在真实设备上踩过、填过的坑。把它比作一套“配方”并不过分——不是你拿到就能全世界通用，但它能给你提供现阶段比较成熟的工程路径。

7.1 遇到这类项目时我的行动顺序

每次接类似的全适配需求，我现在的行动顺序已经非常固定了：

1. 先问清楚PC端和移动端是“同一套页面”还是“结构差异很大的页面”。这决定了你是走样式自适应还是写局部组件。
2. 把两端的核心交互列出来，找出必须“结构性变化”的部分（比如PC表格 vs 移动卡片）。
3. 选定一种主适配方案（rem或vw），不要混用。
4. 用postcss转换业务代码里的尺寸单位。
5. 处理组件库：要么排除，要么单独适配。
6. 用真实设备跑一轮，尤其是iOS Safari的输入框聚焦、安卓低端机的渲染性能。

7.2 对新人最实用的一条建议

我个人这套方案里，如果说只能留下一条建议，那就是：别把自适应的基础开发得过于信仰某一套方案，而是同时掌握vw换算和媒体查询。vw负责等比例缩放的一致性，媒体查询负责不同屏幕下的结构变体，两者是互补关系而不是替代关系。过度依赖其中一样，都会在实际调试时为难自己。

这个项目已经旧了，但里面沉淀下来的那套适配方法论放到今天依旧适用。如果你也在做类似的全端vue项目，不妨把这份配置和经验当作一个起点，再根据你手里的设计稿和组件库做局部调整。手机和电脑屏越来越大、越来越杂，自适应的功课，值得每个前端从业者认真做一遍。

本文还有配套的精品资源，点击获取