【偏门药方】写页面的宽度基准选错了该怎么办？

这是第一篇【偏门药方】，开篇简单介绍一下 -- 本栏目旨在记录平时遇到的稀奇古怪的场景以及解决方案，一般来说大家都是遇不上的，但是一旦遇上那就很容易让人汗流浃背，所以还是有必要记录一下滴。

背景

笔者接手了一个已投产项目，写了一个迭代发现，拿到的是375设计稿，但是写的时候像素怎么都对不上，一看vue.config.js里面，赫然写着414。考虑到马上就到冒烟阶段了，只好硬着头皮把之前375的像素都手动改回414。

后面盘了一下，组内其他项目都是375基准的，就这一个项目刚好被我碰上（该说运气好还是不好呢，既然只有它是异类，那我们肯定得要整改回去啦，万一后面再有同学踩坑就不好了，所以也就有了我们标题上的疑问 -- 页面的宽度基准选错了该怎么办？

方案

项目梳理及评估

因为是已经投产的项目，所以需要评估整改的工作量，看看是否能够在一个迭代周期内一次性整改完，如果无法整改完是否需要过渡方案。

梳理的流程很简单，因为项目本身的结构比较清晰，views目录里都是页面模板，components目录里面都是组件模板，我们只需要跑个脚本把所有文件都列出来即可，后面根据这个文件列表来预估工时以及摊派任务。

随着项目梳理的深入，惊奇的发现一个项目里面既有用414设计稿的页面，又有用375的页面，这基本就把脚本统一修改的路子堵死了。

也许大家会好奇，为啥这么离谱的事情在视觉走查的时候没看出来，因为真正在设备上看的时候是比较难察觉的，375的设计稿在414的基准下会偏小，但是是整个页面的等比变小，所以是很有可能会在视觉走查的时候被忽略的。

既然没法跑脚本批量变更那就只好手动调整了，工时评估其实也很简单，直接算vue模板的文件即可，每个模板大概一个工时可以调整完毕（模板有大有小，平均下来差不多就是一个工时）。

其中有些需要注意的坑

① 写在模板上的内联样式，这类样式一般是没有经过样式预处理的，调整的时候不要忽略这些地方，有可能的话最好都放在style标签里。

② 写在逻辑里的样式，同①，调整的时候不要忽略。

③ 特殊：414页面用了375组件 or 375页面用了414组件，如果有这种情况就尽量一次性改完涉及的组件或者页面，避免误导后续开发的同学；但其实这种情况是不会影响页面展示的，因为我们可以针对不同文件使用不同的转换基准。

过渡方案

笔者实际的落地情况是没有使用过渡方案的，我们专门抽出一个迭代来进行整改，将所有的页面组件都过了一遍。

那如果拆开多个迭代我们还能整改么？可以的，而且成本也不高，前提：使用的css预处理插件是postcss-px-to-viewport（其他插件大概率也是可以的）。

因为postcss-px-to-viewport可以配置include和exclude，所以我们可以将待整改的页面以及组件维护成一个文件列表，在414的基准配置中include这个列表，而在375的配置中exclude它们，这样一来新的页面我们都可以按375基准来开发，旧的页面则可以分期整改。

js 复制代码

// vue.config.js
const pathArr = ['./src/views/test/index.vue'];
// ...
postcss: {
  plugins: [
    require("postcss-px-to-viewport")({
      // ...
      viewportWidth: 375,
      exclude: pathArr
    }),
    require("postcss-px-to-viewport")({
      // ...
      viewportWidth: 414,
      inclue: pathArr
    }),
  ]
}
// ...

尾声

这确实是个很偏门的问题吧:)，要是遇到了也没关系，通过预处理插件的重载我们可以让两种设计基准暂时性的共存，既然可以过渡，那后续自然就可以很轻松的排期完成错误基准模板整改。