前端页面的成功呈现，不仅要求在理想情况下没问题，当一些后台接口访问异常、静态文件获取失败时，仍然需要尽可能提供降级方案或给用户良好的反馈，不至于整个页面的奔溃。今天我将分享一些提高页面健壮性的技巧。
异常处理
主要指数据类型。这种情况最常出现在读取后台数据的时候，尤其是需要取数组、对象等引用类型时，可能后台已经保证会传给你固定的数据类型，但因为种种原因或异常，可能出现本来应该是一个对象或数组的字段变成了null，这是非常之普遍的，如果前端直接取res.xxx或res.length，就会报错，导致程序阻塞。
一般有两种手法来处理这种情况：一种是判空处理，如(res || []).length，（res || {}).name等；另外一种是全部按理想情况写，但是外层用try{...}catch(){...}包裹，一有异常就抛出去，通过过滤错误来确保try后面的代码仍能正常执行。
数据检验
最常出现在表单输入时，用户可能输入各种各样奇怪的东西，比如有前后空格、负数、小数、很长很长的数，重复的数等等，一般我们可以设置一些规则来限制用户操作，比如设置最大输入长度，不能输入负数、小数等等，还有就是表单提交时对不合理的行为做出提示，阻止其进行下一步操作。
能应对怪异的用户行为
我们很难去规范用户使用系统或浏览页面的行为，尤其是行为顺序，可能用户会完全不按照正常的顺序去做一些操作，比如按照相反的顺序来，或交叉顺序操作系统，或疯狂的点击按钮。这不是普遍的情况，但最好能保证你的程序在这种情况下仍然可用， 一般应对疯狂的用户行为，可以用防抖、节流、最大次数限制来做规范，而对于不按套路操作的用户，要么限制其行为，告诉他“请先选择xxxx，再进行xxxx”，或者在程序方面做好兼容。
响应式
这已经是一个很基础的需求，考虑到大部分用户的屏幕尺寸限制，很多高分辨率屏幕都会出厂自带一定的文本缩放，所以实际在浏览器中，视窗的宽度很少有超过1920px的；尤其是笔记本，就算是16英寸的屏幕，1080p全开字也是很小的，所以实际在PC端，做的好的话，会兼容到到1024*768 ~ 1920*1080。同时做好最大最小宽度限制。
注意JS浮点数运算的坑
这是一个历史遗留问题，0.1 + 0.2 !== 0.3是一个大家都知道的梗，所以如果涉及到前端运算的页面，一定要注意浮点数的问题， 常见的手法有用+‘xxx’或parseInt或parseFloat来做字符串转数字，用toFixed来限定小数点的位数等。