版权声明：本文为博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。 本文链接：https://blog.csdn.net/qq_35618493/article/details/88767107

0.前言

这两天在做一款微信小程序的开发，今天在前后端及UI对后面几天的工作进行安排时，发现小程序出了一点小问题。

在win端和mac端分别进行真机调试时，同一部手机通过两个系统上的微信开发者工具进行调试时，产生的效果不同。

1.问题描述

在mac端调试生成的效果如图

，

可以看到失物招领四个字是正常的，但同样的代码在win下的微信开发者工具，生成的效果如图

失物招领四个字有一个被挤下去了。

对应的wxml代码如下

[code]<view class="list_title" hover-class="none" hover-stop-propagation="false">
失物招领
</view>

 对应的样式文件如下

[code].list_title {
font-size: 22rpx;
margin: 0 auto;
}

2.问题分析

2.1手机型号

首先，分别使用组里其他二人的手机扫码调试，发现问题依旧出现。因此，排除手机型号的问题。

2.2代码问题

通过人眼对比win和mac两边的代码，发现代码完全相同。将代码通过git同步后发现，问题依旧存在。但对比win和mac生成的代码包发现，win下代码包为460kb，而mac下为451kb，然而代码相同，猜测是不同环境下的开发者工具产生的代码不同。

2.3真机调试

在两种环境下分别进行真机调试，对比这一行的代码

mac：

win：

发现win下的font-size被转换成了13px。遂百度有关微信小程序rpx转px的问题。在微信官方的社区中，有人说是wxss编译时的问题，可以通过删除wcsc.exe文件来解决。

在console中输入openvendor（），打开文件夹后删除wcsc文件，重新编译后发现问题依旧存在。

2.4 CRLF

对比win和mac生成的wxml文件发现

win下的失物招领两边有一个空格，但mac下是没有的

这时，想起来之前看到的win和mac下的对换行符的定义不同

名词解释

• CR：Carriage Return，对应ASCII中转义字符\r，表示回车
• LF：Linefeed，对应ASCII中转义字符\n，表示换行
• CRLF：Carriage Return & Linefeed，\r\n，表示回车并换行

众所周知，Windows操作系统采用两个字符来进行换行，即CRLF；Unix/Linux/Mac OS X操作系统采用单个字符LF来进行换行；另外，MacIntosh操作系统（即早期的Mac操作系统）采用单个字符CR来进行换行。猜测是因为两种系统CRLF的区别导致了生成效果的不同。

这也就很好的解释了为什么之前win下生成的代码包比mac大的问题，于是通过vscode，将代码的换行符模式改成了LF。重新编译，发现问题解决。

3.总结

win和mac两种不同的操作系统对换行符的定义的不同，偶尔会带来一些排版上的问题。但大部分情况下并不会引起注意，本文也只是给大家在遇到类似的问题时，提供一种解决的思路。