受于时间紧迫，可翻阅文档有限，感觉是因为默认的行高原因，于是我只好发挥老司机的狡猾本质，可以通过行高或者overflow的控制，干掉多余的部分，最终真机界面显示还算统一
如果你要按照像素级别设计稿来做小程序开发的话，控件的小差异还是需要自己来做一些控制（也有可能从根本上就是我个人用错了方法或者理解错了，鉴于文档太少，以后开发者多了大家会有更清晰的认识。）
还有另一个遇到的问题，就是小程序对 image 的默认渲染，这是通过工具查看默认图像的样式
经过多方打听发现小程序的image是按照background-image来实现的，所以所有图像会得到一个初始宽高320 240，而且无法通过auto重置，只可以通过具体的值来重写。
好在微信提供了3种缩放模式，9种裁剪模式，在大多数场景可以满足我们对图片的控制：
例如原图：
scaleToFill 模式
不保持纵横比缩放图片，使图片完全适应
aspectFit
保持纵横比缩放图片，使图片的长边能完全显示出来
aspectFill
保持纵横比缩放图片，只保证图片的短边能完全显示出来
top
不缩放图片，只显示图片的顶部区域
bottom
不缩放图片，只显示图片的底部区域
center
不缩放图片，只显示图片的中间区域
left
不缩放图片，只显示图片的左边区域
right
不缩放图片，只显示图片的右边边区域
top left
不缩放图片，只显示图片的左上边区域
top right
不缩放图片，只显示图片的右上边区域
bottom left
不缩放图片，只显示图片的左下边区域
bottom right
不缩放图片，只显示图片的右下边区域
如果你有更严格的图片设计展示方式，那么可以尝试用一些特殊的方式去控制图像的宽高吧。
还有小程序的button控件，
他的初始样式里并没有border，所以我费尽心思也没能把他重写为一个无边无背景的设计形式，最终为了满足设计稿，个别语义化为按钮的元素，我是用其他更可控的元素来实现的，比如这个界面的发送图片按钮
但是到后来才知道button是通过after来写的样式，开发者工具的调试里完全看不到这个after(┬＿┬).....
除了这些UI开发上的体会，大家也都知道，小程序诞生就不是为了展示，他不适合做纯展示型的东西，主要是做一些功能型的应用。