那这次新版本的更新有哪些亮点呢？《Java开发手册（嵩山版）》特别增加了前后端交互的一些规约，并修复了一些原来存在的一些问题，接下来让我们先品尝一些嵩山版带来的新的滋味吧。
在前后端工程师分工协作愈加普遍的今天（前后端分离，前端干前端的事情，后端干后端的事情），使效率得到大大的提升，但是凡事有利也有弊，分离的同时也带来了很多协作上的问题。本次开发手册新增的前后端规约旨在解决前后端工程师协作上的问题以及让大家规避工作中常见的、易于疏漏的错误，让大家少走弯路。在现在的前后端协作当中沟通就显得极为重要，但是规范大于约定，正所谓“没有规矩，不成方圆”，大到前后端API的约定，小到前后端的时间格式约定，我们都得精心设计已达到最优的效果。walking本人就亲眼看到过身边的同事因为前后端编码不规范，API不规范，没有沟通到位而大打出手的（脾气都太火爆了😥）。用苹果的宣传语来讲便是“唯一的不同，是处处不同”，所以如果每个系统都对应着自己的一套前后端约定那就非常不利于维护，混乱的约定更让系统接手与维护的人头痛不堪。规矩并非枷锁，而是老司机们上路的安全带，有了它，才能让我们在程序的世界里安全的驰骋，去最大可能的提升效率，去创造更大的奇迹。
前后端交互API的约定
在前后端交互的过程当中，API是重中之重，一个好的API应该能够明确协议、域名、路径、请求方法、请求内容、状态码、响应体等7个重要要素。一个好的API约定会让前后端双方能够为接下来的开发工作节省许多时间和沟通的成本，是我们前后端协作的基石。
整数精度丢失的问题
不同于后端程序的各种数字类型的明确区分，在JS的世界里数字只有一种类型，那就是Number类型，后端的API中往往会返回一些状态字段，结果值是0、1、2这些，如果没有约定好前端就不知道这是数字啊还是字符串，还有，前后端传参时如果没有约定好字段类型也会引发后端的数据类型转换异常。而前端的Number类型它其实是双精度浮点数，因此，它造成的麻烦总是使人困惑和痛苦，当我们将一个过大的整数传递给前端的时候，想象一下当它超过了双精度浮点数能最精确表示范围的时候会出现怎么样的悲剧吧？欲知详情如何，请见嵩山版开发手册吧。
系统错误信息与用户提示信息混淆
你是否曾经把异常带到了页面上？你是否把系统的错误提示发给了一脸懵的用户？walking曾经在和别的系统对接的时候，就看到对方把空指针的堆栈信息都返回给我了😱。今天，前后端规约将助你摆脱这样尴尬的境遇。用户体验不仅仅是产品设计需要考虑的部分，作为技术人的我们更应该注重产品本身的质量，因此用户提示一定要与系统本身的错误区分开，给用户更友好的提示也是系统鲁棒性的象征，另外发生错误的时候返回给前端的信息除了上面两种错误信息再搭配上错误码与HTTP状态码一起食用更香哦。
URL参数传递注意长度
很多场景需要我们用URL来做前后端的参数传递，但是比较蛋疼的是URL有最长长度的限制，而不同的浏览器对URL最大长度限制却是不同的。这些不明确的地方都是不易察觉的深坑，不知道栽进去了多少的仁人志士，为了规避掉入这样的深坑，前后端规约中特别指出，对于URL长度限制采用所有浏览器限制的最小值，为2048字节。
不但有文档，还有集成开发工具插件
Java 规约插件
为了让开发者更加方便、快速的将规范推动并实行起来，阿里巴巴基于手册内容，研发了一套自动化的IDE检测插件（IDEA、Eclipse）， 该插件在扫描代码后，将不符合《手册》的代码按Blocker/Critical/Major三个等级显示在下方，甚至在IDEA上，还基于Inspection机制提供了实时检测功能，编写代码的同时也能快速发现问题所在。
Alibaba Cloud Toolkit
从Java代码检查到持续集成、自动化测试、自动部署，全面覆盖研发部署工作场景，支持IntelliJ IDEA、Eclipse、Visual Studio Code等不同IDE，无需对接第三方工具，大幅提升研发效率。 支持一键部署至任意服务器及云端（ECS、EDAS、ACK、ACR、小程序云等），有效降低开发者重复性工作量。
