（二）常量定义
1.【强制】不允许任何魔法值（即未经预先定义的常量）直接出现在代码中。
反例：
// 本例中，开发者 A 定义了缓存的 key，然后开发者 B 使用缓存时少了下划线，即 key 是"Id#taobao"+tradeId，导致 出现故障 String key = "Id#taobao_" + tradeId; cache.put(key, value);尤其是Enum枚举类里
2.【强制】在 long 或者 Long 赋值时，数值后使用大写字母 L，不能是小写字母 l，小写容易跟
数字混淆，造成误解。
说明：Long a = 2l; 写的是数字的 21，还是 Long 型的 2？
（三）代码格式
1.【强制】如果是大括号内为空，则简洁地写成{}即可，大括号中间无需换行和空格；如果是非
空代码块则：
1） 左大括号前不换行。
2） 左大括号后换行。
3） 右大括号前换行。
4） 右大括号后还有 else 等代码则不换行；表示终止的右大括号后必须换行。
2.【强制】左小括号和右边相邻字符之间不出现空格；右小括号和左边相邻字符之间也不出现空
格；而左大括号前需要加空格。详见第 5 条下方正例提示。
反例：if (空格 a == b 空格)
3.【强制】if/for/while/switch/do 等保留字与括号之间都必须加空格。
4.【强制】任何二目、三目运算符的左右两边都需要加一个空格。
说明：包括赋值运算符=、逻辑运算符&&、加减乘除符号等。
5.【强制】采用 4 个空格缩进，禁止使用 Tab 字符。
说明：如果使用 Tab 缩进，必须设置 1 个 Tab 为 4 个空格。IDEA 设置 Tab 为 4 个空格时，请勿勾选Use tab character；而在 Eclipse 中，必须勾选insert spaces for tabs。
正例：（涉及 1-5 点）
// 缩进 4 个空格 String say = "hello"; // 运算符的左右必须有一个空格 int flag = 0; // 关键词 if 与括号之间必须有一个空格，括号内的 f 与左括号，0 与右括号不需要空格 if (flag == 0) { System.out.println(say); } // 左大括号前加空格且不换行；左大括号后换行 if (flag == 1) { System.out.println("world"); // 右大括号前换行，右大括号后有 else，不用换行 } else { System.out.println("ok"); // 在右大括号后直接结束，则必须换行 } }6.【强制】注释的双斜线与注释内容之间有且仅有一个空格。
7.【强制】在进行类型强制转换时，右括号与强制转换值之间不需要任何空格隔开。
正例：
double first = 3.2d; int second = (int)first + 2;8.【强制】单行字符数限制不超过 120 个，超出需要换行，换行时遵循如下原则：
1）第二行相对第一行缩进 4 个空格，从第三行开始，不再继续缩进，参考示例。
2）运算符与下文一起换行。
3）方法调用的点符号与下文一起换行。
4）方法调用中的多个参数需要换行时，在逗号后进行。
5）在括号前不要换行，见反例。
正例：
StringBuilder sb = new StringBuilder(); // 超过 120 个字符的情况下，换行缩进 4 个空格，并且方法前的点号一起换行 sb.append("yang").append("hao")... .append("chen")... .append("chen")... .append("chen");反例：
StringBuilder sb = new StringBuilder(); // 超过 120 个字符的情况下，不要在括号前换行 sb.append("you").append("are")...append ("lucky"); // 参数很多的方法调用可能超过 120 个字符，逗号后才是换行处 method(args1, args2, args3, ... , argsX);9.【强制】方法参数在定义和传入时，多个参数逗号后面必须加空格。
正例：下例中实参的args1，后边必须要有一个空格。
method(args1, args2, args3);
10.【强制】IDE 的 text file encoding 设置为 UTF-8; IDE 中文件的换行符使用 Unix 格式，不要
使用 Windows 格式。
说明：
编码（UTF-8）和换行符（LF/CRLF）是文本文件的基础属性，不同操作系统 / IDE 的默认设置存在差异：
- 编码：Windows 默认 GBK/GB2312，Linux/Mac 默认 UTF-8；
- 换行符：Windows 默认 CRLF（回车 + 换行，
\r\n），Unix/Linux/Mac 默认 LF（仅换行，\n）。规范要求统一为 UTF-8+LF，本质是消除跨平台 / 跨团队的格式冲突，避免代码乱码、版本控制混乱等问题
一、为什么必须统一设置为 UTF-8 编码？
UTF-8 是 “通用字符编码”，统一使用 UTF-8 的核心目的是解决字符乱码问题，同时适配国际化开发，具体原因如下：
1. 彻底规避中文 / 特殊字符乱码
Java 项目中大量使用中文注释、中文日志、国际化文案，若编码不统一：
- 场景 1：开发者 A 用 GBK 编码写中文注释，开发者 B 用 UTF-8 打开文件，注释会变成 “????” 乱码；
- 场景 2：Windows 本地用 GBK 编码开发，部署到 Linux 服务器（默认 UTF-8）后，代码中的中文配置 / 日志会乱码，导致业务逻辑异常（如中文用户名匹配失败）；
- 场景 3：数据库 / 接口传输的是 UTF-8 编码数据，代码编码不一致会导致 “入库乱码”“接口返回乱码”。
UTF-8 兼容所有 Unicode 字符（包括中文、英文、特殊符号），是 Java 生态的 “标准编码”（JDK、Spring 等框架均默认适配 UTF-8），统一后能从根源上杜绝乱码。
2. 适配国际化开发
现代项目多需支持多语言（如中文、英文、日语），UTF-8 是唯一能完整覆盖全球主流语言的编码格式，而 GBK 仅支持中日韩字符，无法满足国际化需求。
3. 避免版本控制工具（Git/SVN）的无效冲突
若团队成员编码不一致，修改同一份文件时，即使只改了一行代码，Git 会检测到 “文件二进制内容变化”（编码转换导致），产生大量无意义的 “编码冲突”，增加代码合并成本。
二、为什么必须使用 Unix 换行符（LF）而非 Windows（CRLF）？
换行符看似是 “小细节”，但会引发版本控制、脚本执行、工具兼容三大核心问题，统一为 LF 的原因如下：
1. 解决 Git 版本控制的 “换行符冲突”（最核心原因）
Git 有 “换行符自动转换” 机制，但如果团队混用 LF/CRLF：
- 场景 1：Windows 开发者提交代码时，Git 自动将 LF 转为 CRLF，Linux 开发者拉取后又自动转回 LF，导致每次提交都显示 “整个文件的换行符被修改”，Git 日志中全是无意义的变更，无法追溯真实的代码修改；
- 场景 2：多人协作时，同一份文件的换行符不一致，合并代码时会出现 “^M”（CR 字符的显示符号），甚至导致代码编译 / 执行异常。
Unix 格式（LF）是 Linux/Mac/ 服务器的标准换行符，统一为 LF 后，跨平台提交 / 拉取代码无换行符转换，Git 日志能精准反映代码变更。
2. 保证 Shell 脚本 / 批处理文件的正常执行
Java 项目中常包含 Shell 脚本（如部署脚本、启动脚本），这类脚本只能在 Unix/Linux 环境执行：
- 若脚本文件用 Windows 换行符（CRLF），Linux 执行时会识别到
\r字符，报错-bash: ./start.sh: /bin/bash^M: bad interpreter: No such file or directory；- 即使手动修改，也会增加部署成本，统一为 LF 后脚本可直接在 Linux 执行，无需额外处理。
3. 适配主流开发工具 / 容器
- 构建工具（Maven/Gradle）、CI/CD 工具（Jenkins）、Docker 容器均基于 Unix/Linux 环境，默认适配 LF 换行符；
- IDEA/Eclipse 等主流 IDE 均支持 LF 换行符，统一设置后无需为不同环境调整。
