codewave-openclaw-installer 1.0.0

package/skills/smart-customer-service/docs/codewave/85./346/234/200/344/275/263/345/256/236/350/267/265/105./344/270/200/346/226/207/344/272/206/350/247/243/345/272/224/347/224/250/345/274/200/345/217/221/350/247/204/350/214/203.md

@@ -0,0 +1,820 @@
+# 一文了解应用开发规范
+
+- [一文了解应用开发规范](#一文了解应用开发规范)
+  - [一、开发规范](#一开发规范)
+    - [1、命名规范](#_1、命名规范)
+    - [2、注释规范](#_2、注释规范)
+    - [3、异常规范](#_3、异常规范)
+    - [4、日志规约](#_4、日志规约)
+    - [5、安全规约](#_5、安全规约)
+    - [6、数据库规范](#_6、数据库规范)
+    - [7、逻辑规范](#_7、逻辑规范)
+    - [8、多人协作使用规范](#_8、多人协作使用规范)
+    - [9、需求实现规范](#_9、需求实现规范)
+    - [10、使用场景规范](#_10、使用场景规范)
+  - [二、项目应用敏感操作规范](#二项目应用敏感操作规范)
+    - [1、制品应用](#_1、制品应用)
+    - [2、多人协作](#_2、多人协作)
+    - [3、事故场景补救](#_3、事故场景补救)
+  - [三、高并发应用的实现](#三高并发应用的实现)
+    - [1、技术选型](#_1、技术选型)
+    - [2、数据建模](#_2、数据建模)
+    - [3、逻辑开发](#_3、逻辑开发)
+    - [4、安全防范](#_4、安全防范)
+    - [5、平台部署](#_5、平台部署)
+
+
+## 一、开发规范
+
+### 1、命名规范
+
+**1.1、应用命名**
+
+- 【推荐】应用名称：由1至64个字符组成，具体命名应根据业务客户需求确定，建议在应用名称中标明"【勿删】"以提醒相关人员不要删除该应用
+
+    > 正例：采购管理系统【勿删】
+    >
+    > 反例：zxrtest24022201
+
+- 【推荐】应用标识：由1至28位小写字母和数字的组合，必须以字母开头，以字母或数字结尾。应用标识是唯一ID，可使用应用名称的小写字母搭配应用版本。如果出现重复，可以再追加额外标识确保唯一性。
+
+    > 正例：cgglxt3v3
+    >
+    > 反例：123456
+
+**1.2、页面命名**
+
+- 【强制】页面名称：采用小驼峰命名（lowerCamelCase）
+
+    > 正例：homePage
+    >
+    > 反例：PMS
+
+**1.3、逻辑变量命名**
+
+- 【强制】逻辑名、参数名、成员变量、局部变量都统一采用小驼峰命名（lowerCamelCase）风格。
+
+    在增加、删除、修改和查询功能的具体实现中，统一使用以下5个单词，不得使用其他单词，以确保各个端的统一性（add、delete、update、get、load）
+
+  - 获取单个对象的方法用 get 做前缀
+
+  - 获取多个对象的方法用 load 做前缀
+
+  - 获取统计值的方法用 count 做前缀
+
+  - 插入的方法用 save/insert 做前缀
+
+  - 删除的方法用 remove/delete 做前缀
+
+  - 修改的方法 update 做前缀
+
+    > 正例：getRoleUser
+    >
+    > 反例：logic1
+
+**1.4、数据结构命名**
+
+- 【强制】实体、数据结构、枚举应采用大驼峰命名（UpperCamelCase）风格，每个单词的第一个字母大写，其他字母小写，不得添加任何符号。数据结构最终会被映射为实体类，所以需要保证一定的命名规范。
+
+    > 正例：AuditLog
+    >
+    > 反例：Entity1
+
+- 【强制】数据实体变量命名：变量命名都统一采用小驼峰命名（lowerCamelCase）风格，如果是布尔类型的变量，不要加is。数据实体最终会被映射为数据库表的，所以需要保证一定的命名规范
+
+    > 正例：deleted
+    >
+    > 反例：isDeleted
+
+**1.5、流程命名**
+
+- 【强制】流程命名：采用大驼峰命名(UpperCamelCase)，每个单词的第一个字母大写，其他字母小写，不要添加任何符号。清晰表示流程的业务含义，便于清晰定位流程。
+
+    > 正例：TicketCheckProcess
+    >
+    > 反例：Process1
+
+**1.6、枚举命名**
+
+- 【强制】枚举命名应采用大驼峰命名(UpperCamelCase)，使用对应字段名称。
+
+    > 正例：UserStatusEnum
+    >
+    > 反例：Enum1
+
+### 2、注释规范
+
+**1.1、页面注释**
+
+- 【强制】页面注释：“页面属性”-“标题”处添加注释，以表明页面的含义
+
+    > 正例：login(登录页)
+    >
+    > 反例：login
+
+**1.2、逻辑注释**
+
+- 【强制】逻辑注释：“服务端逻辑”-“属性”-“描述”处添加注释，注释表明逻辑的含义
+
+    > 正例：loadRoleByListUserId(根据list用户id查询角色(判断角色是否已添加该用户))
+    >
+    > 反例：logic1
+
+**1.3、数据注释**
+
+- 【强制】数据注释：实体、数据结构、枚举可以在属性的“描述”中添加注释，注释表明该数据的含义，有助于快速定位。
+
+    > 正例：AuditLog(审计日志)
+    >
+    > 反例：AuditLog
+
+**1.4、流程注释**
+
+- 【强制】流程注释：流程可以在属性的“标题”处添加注释，注释表明该流程的含义。
+
+    > 正例：TicketCheckProcess(验票流程)
+    >
+    > 反例：Entity1
+
+### 3、异常规范
+
+**1.1、空指针异常**
+
+- 【强制】防止 NullPointerException(空指针)，做好非空判断。
+
+    > 正例：
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_1.png" class="imgStyle" style="width:400px;" />
+
+**1.2、异常内容提示**
+
+- 【强制】异常内容提示要准确，同时不要泄露其他无关信息。例如，提示说明账号或密码错误，不要直接提示密码错误，或者账户错误，否则会被利用去猜测账户或密码。
+
+    > 正例：
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_2.png" class="imgStyle" style="width:400px;" />
+
+### 4、日志规约
+
+**1.1、日志输出位置**
+
+- 【强制】日志的打印位置一般考虑在方法的入口和出口。
+  
+    可以记录方法被调用的情况，包括方法的参数和调用者的信息以及方法的返回值或执行结果，日志要精简，避免将所有的返回结果全部输出，占用性能资源。
+
+    > 正例：
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_3.png" class="imgStyle" style="" />
+
+**1.2、日志调试**
+
+- 【强制】日志调试：日志的调试用于开发阶段，当应用稳定准备上线时，关闭不必要的日志。
+
+    正式上线时，关掉不必要的日志有助于性能的提升，和减免安全性问题。
+
+    > 反例：
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_4.png" class="imgStyle" style="" />
+
+**1.3、日志输出场景**
+
+- 【强制】日志输出：当逻辑返回的数据结果，在明确前提存在有数据量较大的情况下，考虑关闭方法输出的日志打印或打印关键数据。
+
+    直接日志输出某逻辑的返回结果，当返回结果数据量较大时，会有性能问题。
+
+    > 反例：打印需要删除的列表信息，但是列表中数据量较多，此时应考虑关闭。
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_5.png" class="imgStyle" style="" />
+
+**1.4、日志级别**
+
+- 【强制】日志级别：生产环境禁止输出 debug 日志；有选择地输出 info 日志；如果使用 warn 来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。
+
+    日志级别由低到高为：
+
+    - 【DEBUG】：输出一些调试信息，比如：“用户登录成功，用户ID：1234”
+
+    - 【INFO】：输出一般信息，比如：“服务器已启动，监听端口：8000”
+
+    - 【WARN】：输出警告信息，比如：“数据库连接超时，正在尝试重新连接”
+
+    - 【ERROR】：输出错误信息，比如：“支付交易处理失败，交易ID：5678”
+
+    如果制品应用的日志级别是INFO，则WARN和ERROR类型的日志（高于INFO级别）都会打印，DEBUG不会输出（低于INFO级别）。
+
+### 5、安全规约
+
+**5.1、登录认证**
+
+- 【强制】认证端：登录用户的身份进行标识和鉴别，并保证鉴别过程在服务端（后端）完成。
+- 【推荐】密码定期修改：至少每X个月修改口令，并限制用户在更改口令时禁止使用重复口令。
+- 【推荐】重复认证：已登录系统的用户在执行“敏感操作”时被重新认证。
+- 【推荐】账户逐出：设置账号状态，当账户有违规操作时，可通过修改状态强制下线，不允许其后续操作。
+
+**5.2、访问控制**
+
+- 【强制】权限控制：页面的访问必须配置权限控制，和角色关联。
+
+    > 正例：
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_6.png" class="imgStyle" style="" />
+
+- 【强制】水平权限控制：针对某些实体操作时，当业务场景要求只允许“本人操作”时，必须添加逻辑来进行控制。
+
+    说明：场景需求"本人操作时"，必须将当前登陆人和实体关联人进行查询匹配，防止其他人篡改本人数据。
+
+    > 正例：具体示例为将用户id 和 发帖人id 进行匹配，匹配成功，才允许进行下一步操作。
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_7.png" class="imgStyle" style="" />
+
+**5.3、数据安全**
+
+- 【强制】数据脱敏：用户敏感数据禁止直接展示，必须对展示数据进行脱敏。
+- 【推荐】返回有效数据：浏览器F12是可以查看接口的返回数据，接口数据在返回时，禁止将不必要的数据。例如前端页面仅展示 订单.单号数据，但是接口同时返回了 订单.单号，订单.时间，订单.金额 等相关数据，存在安全风险。
+
+- 【推荐】数据加密：涉密、敏感等数据，需要加密，然后再入库。
+- 【推荐】加密工具：使用的加密算法要以安全性高的、最新的加密算法来进行加密。
+- 【推荐】参数管理：隐私参数（密钥、私钥）禁止应用内明文使用，需通过参数配置功能添加至应用内并根据隐私级别开启'隐私安全'设置。
+
+    <img src="../assets/didaimayingyongkaifaguiyue_202503031025_8.png" class="imgStyle" style="" />
+
+**5.4、审计日志**
+
+- 【推荐】审计日志：根据应用的场景需要，结合[审计日志依赖库](https://community.codewave.163.com/CommunityParent/CodeWareMarketLibraryDetail?id=3029107391323648&isLatest=false&isClassics=false)，开启审计日志，记录应用的网络请求
+
+**5.5、文件安全**
+
+- 【推荐】文件上传白名单：和应用方沟通明确具体业务场景有哪些文件要进行上传，以白名单进行控制 ，禁止上传无关类型文件。
+
+    > 正例：
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_9.png" class="imgStyle" style="" />
+
+- 【推荐】文件下载策略：明确业务场景，指定文件的访问策略，推荐”用户登陆后“访问策略，否则访问文件暴漏路径后会被任意下载。
+
+    > 正例：配置文件访问策略"用户登陆后可访问"
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_10.png" class="imgStyle" style="" />
+
+- 【推荐】文件上传大小：明确业务场景，指定文件上传大小，如果有具体某一个场景的考虑使用大文件上传组件，直接修改”单个文件上传“大小配置，会存在大文件 占用流量带宽，影响应用内存风险。
+
+    > 正例：
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_11.png" class="imgStyle" style="" />
+
+**5.6、数据库安全**
+
+- 【推荐】逻辑删除：推荐使用“逻辑删除”，则对数据库中的记录添加一个状态字段，来表示数据是否有效。例如，以status字段来控制这条数据 是否“存在 ”，删除则状态设置为false，未删除状态则为true，而不是真实删除该条记录。
+
+    > 正例：
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_12.png" class="imgStyle" style="" />
+
+- 【推荐】物理删除：真实进行物理删除之前，需要先进行数据备份，然后删除。
+
+### 6、数据库规范
+
+**1.1、表名**
+
+- 【强制】表名：对应数据实体名，采用大驼峰命名(UpperCamelCase)，每个单词的第一个字母大写，其他字母小写。
+
+    > 正例：AuditLog
+    >
+    > 反例：w\_d\_m\_p
+
+- 【强制】表名路由：当应用存在多个模块时，表前缀命名为“模块名”+业务表。
+
+    > 正例：OMS\_Order
+
+**1.2、表字段**
+
+- 【强制】字段长度：对于String类型，设定合适的长度以容纳数据，但避免过度设定长度浪费空间。例如，当字段的业务含义为“名字”等，使用平台默认的最短长度varchar(255)
+
+    > 正例：varchar(255)
+    >
+    > 反例：varchar(4000)
+
+- 【强制】字段类型：如果数据都是数字，考虑Integer、Decimal等数字类型，避免使用String类型。
+
+    > 正例：Integer
+    >
+    > 反例：varchar(255)
+
+- 【强制】字段名称：变量都统一使用小驼峰命名( lowerCamelCase) 风格，不要加数字，平台会自动转成合理名称
+
+    > 正例：eventType
+    >
+    > 反例：property1
+
+- 【推荐】字段拆分：字段对应的数据内容中都具备多重业务含义时，可以将单字段拆分为多字段
+
+    例如，某字段time的值为2019-12-31，当有场景前端需要根据2019年，年的维度来展示数据时，则需要将time，拆分为三个字段，yearTime、monthTime、dayTime，依次存储年、月、日。
+
+    > 正例：year字段单独记录年
+    >
+    > 反例：property1字段记录年-月-日，后期在此字段按年统计
+
+    <img src="../assets/didaimayingyongkaifaguiyue_202503031025_13.png" class="imgStyle" style="" />
+
+- 【推荐】字段冗余：字段允许适当冗余，以提供查询性能，但需要考虑数据一致。冗余字段不应是频繁修改的字段，不应是超过varchar (255)的字段。
+
+    > 正例：姓名、名称等使用频率高，长度短，基本不会变动的，适当冗余可以减少关联查询
+
+**1.3、表索引**
+
+- 【强制】表索引：合适的索引可以提升表的查询效率，索引的创建在区分度明显的字段上，索引的数量单表创建2-4个索引。
+
+    创建索引时，要明确如果有一个字段的所有数值都是不同的，可以对索引进行勾选"唯一索引"。
+
+    > 正例：有模糊查询搜索需求的”名称"等类型的字段可以创建索引
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_14.png" class="imgStyle" style="" />
+    > 反例：所有字段都创建索引。
+
+- 【推荐】页面展示的数据排序：当需要排序时，考虑对该字段添加索引，以保证性能。
+
+    > 正例：“页面展示数据顺序”配合“数据表索引”。页面上的数据按照日期时间倒叙展示，同时要和表字段createdTime配合索引使用，效率更高
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_15.png" class="imgStyle" style="" />
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_16.png" class="imgStyle" style="" />
+
+**1.4、表关系**
+
+- 【强制】多对多：表关系是多对多的情况下，需要创建一张中间关联表，中间关联表的命名要写明"被关联 表名"+"mapping"的命名，中间关联表存储的必须是两张被关联表的唯一字段（可以是id、name等）。
+
+    > 正例：合理命名、关系准确。
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_17.png" class="imgStyle" style="" />
+
+
+- 【推荐】冗余字段 ：一对一、一对多关联下场景下，为了减少多一次表的查询，开发时会将一个字段同时创建在主表和子表上，但如果该冗余字段经常需要执行update时，则要同时维护主表和子表的数据，维护成本变高，所以在冗余字段不经常发生更新的时候，可以考虑使用冗余字段，但不能冗余过多字段。
+
+    > 正例：在不经常执行update的“子表”上建立“主表”的冗余字段，便于减少主表的查询次数。
+    >
+    > 反例：在子表上随意创建冗余字段。
+
+### 7、逻辑规范
+
+**7.1、空值判断**
+
+- 【强制】空值判断：开发逻辑时，要注意基础的空值判断避免引起空指针异常。
+
+    > 正例：赋值时，特别是在循环赋值中，添加if判断，判断循环中的值是否为空，再进行赋值，不然可能会报空值异常。
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_18.png" class="imgStyle" style="" />
+    >
+    > 反例：不判断，直接赋值，会有空指针的风险
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_19.png" class="imgStyle" style="" />
+
+**7.2、sql查询**
+
+- 【强制】sql查询：sql入参查询时，要做参数空值（null和""空字符串）的判断。
+
+    > 正例：根据入参messageType(字符串)，判空后，再去查询TInternalMessage实体的数据
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_20.png" class="imgStyle" style="" />
+    > 反例：非判空后，直接去查询TInternalMessage实体的数据，浪费了一次IO操作，并且返回空结果
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_21.png" class="imgStyle" style="" />
+
+**7.3、for循环**
+
+- 【强制】for循环IO：禁止在for循环中执行数据库查询方法（list、get等方法）。
+
+    > 正例：数据库、sql查询应在循环之前（将一个实体塞入一个list中）。
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_22.png" class="imgStyle" style="" />
+    >
+    > 反例：在for循环中调用了get方法，有多少条id将会执行多少次get方法，然后通过add内置函数将所有结果集合，最后传出所有查询用户信息
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_23.png" class="imgStyle" style="" />
+
+- 【强制】for循环嵌套：禁止在for循环中嵌套for循环（不能超过2层）。
+
+    > 正例：构建map，通过map内置函数中的get方法来尽可能减少循环次数
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_24.png" class="imgStyle" style="" />
+    > 反例：for循环嵌套
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_25.png" class="imgStyle" style="" />
+
+- 【强制】for循环第三方：禁止在for循环中调第三方接口。
+
+    > 正例：接口调用在循环之外
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_26.png" class="imgStyle" style="" />
+    >
+    > 反例：循环之内调用第三方接口
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_27.png" class="imgStyle" style="" />
+
+**7.4、逻辑替换JOIN语句**
+
+- 【强制】当查询多条主表数据时，经常出现通过list方法将主表数据查询后，for循环遍历主表数据，遍历数据语句查询子表数据，以上方式存在严重的性能问题；建议通过以下步骤组合完成：
+
+    1. list查询主表数据；
+    2. for循环遍历主表数据得到主表IdList集合，以主表IdList集合调用 子表的list方法子表，获取子表数据；
+    3. 将子表数据在逻辑中转成`Map<主表Id，子表记录>`或是`Map<主表Id，List<子表记录>>`；
+    4. 再次for循环遍历主表，从步骤3中的map，通过`map.get(主表.id)`得到子表数据，完成赋值。
+
+    > 正例：采用"订单-商品"的案例，来将 订单 inner join 商品的sql查询，替换成逻辑实现；
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_28.png" class="imgStyle" style="" />
+    > 反例：直接用订单 inner join 商品 查询
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_29.png" class="imgStyle" style="" />
+
+**7.5、入参为null值去查询数据库**
+
+- 【推荐】入参为null值时，当有场景需要进入页面时展示数据，此时要默认根据时间为入参，将数据结果分页查询，如果参数为null时，不推荐执行sql语句，在逻辑层面上直接过滤掉，null入参作为数据库查询，有极大的性能问题风险。
+
+    > 正例：入参messageType判空
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_20.png" class="imgStyle" style="" />
+
+**7.6、重复性逻辑可以封装，减少逻辑开发量**
+
+- 【推荐】重复性的逻辑在入参和出参都是相同的情况下，可以进行逻辑封装，在多场景复用，减少逻辑开发量，底层可以对依赖库等进行逻辑层面的二次封装。
+
+    > 正例：封装loadUserByUserId逻辑,然后进行复用
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_31.png" class="imgStyle" style="" />
+
+**7.7、复杂逻辑对应复杂sql的实现**
+
+- 【推荐】当sql中存在对某个字段进行方法year、count()、计算时；当sql出现多表join时；当sql中存在group by等场景时，可以通过拆分字段、逻辑上关联、利用Map的方式来解决group by
+
+    > 正例：以年维度来gourp by订单的 替换逻辑，同样使用 count()、join等语句。
+    >
+    > <img src="../assets/didaimayingyongkaifaguiyue_202503031025_32.png" class="imgStyle" style="" />
+    > 反例：直接使用复杂的sql语句，后续容易造成巨大的性能隐患。
+
+### 8、多人协作使用规范
+
+**8.1、协作前提**
+
+- 【强制】多人协作：官方建议使用多人协作开发功能，不建议多人同时开发一个副本，使用说明文档：[多人协作使用文档](../30.应用生命周期管理/120.多人协作开发/10.多人协作概念介绍.md)。
+
+    > 正例：多人协作开发功能
+    >
+    > 反例：同时开发一个副本
+
+**8.2、协作描述**
+
+- 【强制】页面逻辑、全局逻辑的资源描述必填并写明创建人，可使用姓名缩写
+
+    > 正例：getCompanyInfoByUserId：通过userId查询公司信息-dm
+
+**8.3、协作建模**
+
+- 【强制】数据建模需提前在主应用中完成。
+
+**8.4、协作分支**
+
+- 【强制】基于主应用创建属于自己的协作副本，创建副本的时候默认选择主分支，并在自己的协作副本进行开发。开发完成后统一在主应用进行分支的拉取。
+
+**8.5、协作备份**
+
+- 【强制】开发过程中需及时进行备份操作，避免内容丢失。
+
+### 9、需求实现规范
+
+**9.1、表单规范**
+
+- 【强制】宽度规范：同一个表单中单行输入、数字输入和选择框宽度需一致。
+- 【强制】单行输入：开启清除按钮，除非特殊说明否则数据入库前需使用trim()函数去掉前后空格。
+- 【强制】多行输入：需开启显示字数统计，可输入最大字符数(默认200)，字数统计位置在输入框内，除非特殊说明否则数据入库前需使用trim()函数去掉前后空格。
+- 【强制】数字输入框：如果是小数，精度默认0.01；，除非特殊说明否则数据入库前需使用trim()函数去掉前后空格。
+- 【强制】选择框：超过10条数据需要开启可筛选，以选择框文本字段做模糊匹配；转换器选择Json；超过50条数据需开启分页；开启清除按钮。
+- 【强制】多选组：转换器选择json。
+
+**9.2、数据查询**
+
+- 【强制】查询重置：查询必须有“重置”功能。
+- 【强制】序列固定：数据表格序号、关键列、操作列需固定。
+- 【强制】排序：日期、数字、状态字段必须有排序。
+- 【强制】空值展示过滤：所有显示的的内容，需做空值判断，如果为空则隐藏或替换成--、/等字符，不允许出现null，或空标签等内容。
+- 【强制】分页展示：从数据库查询数据全部用后端分页，页面临时使用的List<>数据可前端分页。
+- 【强制】下拉选项：需要搜索的字段，实体属性类型不能设置为List<>或map<>。
+- 【强制】使用SQL查询，注意处理Null值问题，如果范围查询在筛选条件中，且允许无最大值或最小值，使用比较运算符>=，<= 等；最大值最小值必须都有，可使用`between...and...`
+
+**9.3 、流程开发**
+
+- 【强制】流程变更时：需要将历史流程实例全部结束(OA请假流程为例:所有申请均需流转到结束节点)后再发布，使得新流程生效。
+
+**9.4、其他规范**
+
+- 【推荐】删除操作二次确认：涉及到数据库中的数据的删除的时候，所有删除动作必须有二次确认。
+- 【强制】User表使用：所有显示用户名、昵称的地方不允许左连User表，只能选择用户名和昵称列查询。
+- 【强制】逻辑调用：不允许在ForEach循环中调用create/update/get逻辑
+- 【推荐】空值判断：对查询后的数据、数组等做处理，均需做非空判断。
+
+### 10、使用场景规范
+
+**10.1、文件上传组件**
+
+- 【推荐】文件上传组件默认使用50M传输大小，当超过300M以上，同时需要修改ingress的请求超时时间，所以300M以上时考虑使用大文件上传组件。
+- 【推荐】downloads接口使用，下载的文件需要提前明确文件大小，否则会带来内存问题，使用是要保证传参规范fileName的参数填写，否则会出现下载文件乱码情况。
+
+## 二、项目应用敏感操作规范
+
+### 1、制品应用
+
+- 修改应用前可以进行备份，备份方式不限于应用备份、复制页面、日志备份(云服务器侧)，确保不会因为误操作而导致代码丢失。
+- 谨慎删除不熟悉应用的任何代码！若确实有场景需要删除部分代码，必须和客户/开发者确认改代码业务影响，同时检查改代码层级关系，确保不会影响到子组件及其下事件逻辑；删改逻辑代码时一定要确认引用关系，若有引用的，必须二次和客户/开发者确认是否可删除。在修改逻辑，可将原有逻辑拖出流水线，尽可能保留原有逻辑恢复方式。
+- 发布前必须检查是否有丢失的组件或逻辑，一旦发布就不可以再撤回了。
+
+### 2、多人协作
+
+- 严格遵守多人协作操作规范[(多人协作操纵规范)](../30.应用生命周期管理/120.多人协作开发/10.多人协作概念介绍.md)，建议使用副本应用，避免多人开发同一个应用副本。
+- 代码合并等操作在操作前必须备份，仔细检查冲突项，避免因代码拉取或合并导致代码丢失。
+
+### 3、事故场景补救
+
+- 若误删代码，保留现场，不要再进行操作，IDE页面不要关闭，尽可能保留事故现场的完整【页面缓存可将内容恢复】。
+- 若多人协作合并导致代码丢失的，可联系开发调用运维接口进行最近一次合并的代码进行回滚（注意不要再进行任何拉取合并等操作）。
+
+## 三、高并发应用的实现
+
+
+### 1、技术选型
+
+**1.1 数据库**
+
+【推荐】单表数据量大于千万时，使用分布式数据库以实现数据的高可靠性、可扩展性和性能。
+
+> 说明：分布式数据库能够分散数据存储和处理负载，以应对大规模数据的需求。
+
+**1.2 缓存**
+
+【推荐】QPS（每秒查询率）>500的接口，使用redis连接器，以提高系统的响应速度和降低数据库压力。
+
+> 说明：Redis能够快速读取数据以及缓存频繁访问的数据，减少对数据库的直接访问。
+
+**1.3 消息队列**
+
+【推荐】单个服务端逻辑处理时间>2s时，使用Kafka、RabbitMQ连接器等进行异步处理，降低系统的实时压力。
+
+> 说明：消息队列可以将耗时的任务异步处理，避免阻塞主要逻辑。
+
+**1.4 搜索引擎**
+
+【推荐】中等到大规模的数据集（数据量>千万）使用Elasticsearch依赖库进行搜索
+
+> 说明：Elasticsearch专注于实时搜索和大规模数据的分布式处理。
+
+### 2、数据建模
+
+- 【推荐】字段允许适当冗余，以提高查询性能（避免联表查询），但必须考虑数据一致。冗余字段应遵循：
+
+  - 不是频繁修改的字段。
+  - 不是 varchar 超长字段，更不能是 text 字段。
+
+  > 正例：商品类目名称使用频率高，字段长度短，名称基本一成不变，可在相关联的表中冗余存储类目名称，避免关联查询。
+
+- 【推荐】单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。
+
+    > 说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。
+
+- 【强制】业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。
+
+    > 说明：不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。
+
+- 【强制】三个表禁止 join（联表查询）。需要 join 的字段，数据类型必须绝对一致；多表关联查询时，保证被关联的字段需要有索引。
+
+    > 说明：即使双表 join 也要注意表索引、SQL 性能。已有的多表join可使用逻辑替换JOIN语句。
+
+- 【推荐】建组合索引的时候，区分度最高的在最左边。
+
+    > 正例：如果 where a=? and b=?，a 列的几乎接近于唯一值，那么只需要单建 idx\_a 索引即可。
+    > 存在非等号和等号混合判断条件时，在建索引时，请把等号条件的列前置。如：where c>? and d=?那么即使 c 的区分度更高，也必须把 d 放在索引的最前列，即建立组合索引 idx\_d\_c。
+
+- 【推荐】explain执行计划优化sql
+
+    开发环境打开debug日志（IDE上方的更多设置>应用配置>系统参数配置>添加系统参数>debug日志打印），对于复杂或者执行较慢的 SQL 查询（执行时间大于1秒），可以通过日志获得完整的 SQL，并使用 "EXPLAIN" 命令获取执行计划，以评估当前索引的效率，确定是否需要新增或者删除索引来优化查询性能。需要注意的是，Websql 暂时不支持执行计划，因此可以使用其他数据库工具（如 Navicat、DBeaver）进行直连，或者进入服务器通过命令行连接。另外，也可以在 Websql 中导出数据和结构，然后导入到本地数据库进行分析。
+
+    SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，如果可以是 consts最好。
+
+    说明：
+
+    1） consts 单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。
+
+    2） ref 指的是使用普通的索引（normal index）。
+
+    3） range 对索引进行范围检索。
+
+    反例：explain 表的结果，type=index，索引物理文件全扫描，速度非常慢，这个 index 级别比较 range还低，与全表扫描是小巫见大巫。
+
+- 【推荐】领域驱动设计
+
+    将软件系统建模为与业务领域相关的概念和实体,可以更好地划分业务领域、定义业务实体和其行为，以及规划系统中不同部分之间的交互。
+
+    > 正例：在一个电子商务平台的数据库设计中，使用领域驱动设计将商品、订单、用户等核心业务概念直接映射为数据库中的实体，定义它们的行为和属性，并规划系统中不同部分之间的交互。例如，将订单作为一个聚合根，将商品作为实体，定义它们之间的关系，以及用户的行为和权限。
+    >反例：在一个传统的数据库设计中，仅仅关注数据库表的关系和结构，而忽视了与业务领域相关的概念和实体，导致数据库模型并不直接反映实际业务的需求，难以理解业务逻辑和满足业务变化。
+
+### 3、逻辑开发
+
+- 【推荐】接口性能自测
+
+    参考数据：IDE3.8 开发环境，MySQL 5.7数据库，1核2GB的服务器配置，拖拽实体生成列表，后端接口压测结果如下。
+
+    <table>
+        <tbody>
+            <tr>
+                <td rowspan="2">测试场景</td>
+                <td colspan="7">接口耗时（ms）</td>
+            </tr>
+            <tr>
+                <td>1并发</td>
+                <td>20并发</td>
+                <td>50并发</td>
+                <td>100并发</td>
+                <td>200并发</td>
+                <td>500并发</td>
+                <td>1000并发</td>
+            </tr>
+            <tr>
+                <td>新增数据</td>
+                <td>23</td>
+                <td>66</td>
+                <td>67</td>
+                <td>68</td>
+                <td>128</td>
+                <td>1231</td>
+                <td>2463</td>
+            </tr>
+            <tr>
+                <td>删除</td>
+                <td>32</td>
+                <td>62</td>
+                <td>68</td>
+                <td>79</td>
+                <td>107</td>
+                <td>903</td>
+                <td>3407</td>
+            </tr>
+            <tr>
+                <td>修改</td>
+                <td>29</td>
+                <td>68</td>
+                <td>74</td>
+                <td>82</td>
+                <td>104</td>
+                <td>1095</td>
+                <td>2399</td>
+            </tr>
+            <tr>
+                <td>查询</td>
+                <td>18</td>
+                <td>55</td>
+                <td>58</td>
+                <td>64</td>
+                <td>74</td>
+                <td>1119</td>
+                <td>3119</td>
+            </tr>
+        </tbody>
+    </table>
+
+    使用压测工具，结合业务的qps峰值对后端接口测试，在1并发、20并发下差别不超过100%，20并发、50并发下差别不超过100%，50并发、100并发下差别不超过100%，以此类推。峰值超过1000并发建议新建副本发布生产环境选泽多副本后压测。
+
+    > 测试工具如apifox：<https://apifox.com/help/automated-testing/executing-test/performance-test>
+    > 在进行压力测试时，需要尽量模拟真实生产环境中的数据量。绝大多数低代码应用在开发阶段正常，但一上线就崩溃的情况通常是由于数据量大幅增加所致。
+
+- 前端处理
+
+    在提交后执行页面重定向,简单来说就是当用户提交连表单后,跳转到一个重定向的信息页面,这样就避免用户按F5刷新导致的重复提交,而且也不会出现浏览器表单重复提交的警告,也能消除按浏览器前进和后退导致同样重复提交的问题。对按钮添加防抖效果也是类似的，当然，客户端防止重复提交并不是绝对可靠的，优点是实现起来比较简单。
+
+    ```JavaScript
+    this.logicThrottle = throttle(this.draw, 2000); // 节流，2000ms
+    this.logicThrottle1 = throttle(this.click, 2000); // 节流，2000ms
+
+    that = this;
+    function throttle(func, delay) {
+        let inThrottle;
+        return (...args) => {
+            if (!inThrottle) {
+                func(...args);
+                inThrottle = true;
+                setTimeout(() => (inThrottle = false), delay);
+            }else{
+                that.tooFast();
+            }
+        };
+    }
+    ```
+
+- 使用唯一索引防止新增脏数据
+
+    利用数据库唯一索引机制，当数据重复时，插入数据库会抛出异常，保证不会出现脏数据。
+
+- 乐观锁（一般用于更新）
+
+    如果更新已有数据，可以进行加锁更新，也可以设计表结构时使用乐观锁，通过version来做乐观锁,这样既能保证执行效率，又能保证幂等，乐观锁的version版本在更新业务数据要自增`update table set version = version + 1 where id = #{id} and version = #{version}`
+
+    > 示例: 当有重复请求的时候，第一个请求会获取当前商品的version版本号，得到的version为1，紧接着由于第一个请求还没更新商品的version，第二个请求获取的version依然也是1，这时候第一个请求操作更新的时候带上version并作为条件并且自增更新，这时候商品的version就会变成2，当第二个请求去操作更新的时候明显version不一致导致更新失败。
+
+- 防重表
+
+    以支付为例: 使用唯一主键去做防重表的唯一索引，比如使用订单号作为防重表的唯一索引，每一次请求都根据订单号向防重表中插入一条数据，插入成功说明可以处理后面的业务，当处理完业务逻辑之后删除防重表中的订单号数据，后续如果有重复请求，则会因为防重表唯一索引原因导致插入失败，直接返回操作失败，直到第一次请求返回结果，可以看出防重表作用就是加锁的功能。
+
+- 全局唯一号
+
+    比如通过source来源 + 唯一序列号传入给后端，后端来判断请求是否重复，在并发时只能处理一个请求，其他相同并发请求要么返回请求重复，要么等待前面请求执行完成后再执行。
+
+- Redis分布式锁
+
+    使用Redis连接器setIfAbsentWithExpire方法、deleteKey方法创建并释放分布式锁。
+
+- 【推荐】事务管理
+
+    服务端逻辑涉及到增删改时，开启事务（选中逻辑后在右侧属性面板中开启事务），只有查询逻辑不开启（开启事务会影响性能）。
+
+    > 说明：数据库事务影响该逻辑和子逻辑中的实体增删改逻辑操作:
+    > - 发生异常时，回滚数据库操作；
+    > - 未发生异常时，会在逻辑结束时提交数据库操作。
+    > - 对跨数据源的逻辑开启事务暂不生效。
+
+- 【推荐】连接池配置
+
+    调大数据库连接池最大连接数（IDE上方更多设置>应用配置>系统参数配置>添加系统参数>数据库连接池最大连接数）
+
+    > 说明：并发情况下sql查询慢时，数据库连接池的最大连接数决定了数据库可以同时处理多少个连接，调大能够提高系统对数据库的并发访问能力，默认值为10，可调整至20、50。
+
+- 【推荐】业务告警
+
+    在业务层面，记录业务成功和失败次数，并设置相应的告警规则。
+
+    > 说明：当业务开始时，向自定义的任务表（task\_info）插入一条数据；业务结束时，将状态修改为成功。随后设置定时任务检测，一旦在单位时间内业务成功率低于95%（告警规则），通过邮件或短信等方式通知相关人员。
+
+- 【建议】心跳检测
+
+    对依赖的第三方系统（调用接口、连接器）进行定时心跳检测，以确保这些系统的可用性。通过监测第三方系统的响应状态，可以及时发现并解决潜在的问题，从而避免因依赖系统故障而导致的业务中断或异常。
+
+- 【建议】应用限流
+
+    使用依赖库限制应用流量。
+
+### 4、安全防范
+
+- 【建议】接口防重放
+
+    防止恶意用户或恶意软件抓包，对接口进行重复调用，保护系统免受重放攻击的影响。
+
+    方案：引入前端依赖库"cw\_cryptojs\_library"，和后端依赖库"custon-api-filter"
+
+    原理：前端在每次请求前使用privateKey、nonce、timestamp生成sign，并增加lib-nonce、lib-timestamp、lib-sign请求头，后端将防重放数据存储在redis中，效验timestamp是否过期，sign是否合法且未被使用。
+
+- 【建议】请求响应体加密
+
+    通过对请求响应体进行加密，可以有效保护数据的安全性和隐私性，降低敏感数据泄露的风险。
+
+    方案：引入接口加解密局部模板。
+
+    原理：前端针对/api接口对请求体进行sm2 c1c2c3加密，从应用配置中获取公钥，后端使用统一拦截解密。后端针对所有响应体进行sm2 c1c2c3加密，前端统一拦截解密
+
+### 5、平台部署
+
+- 【强制】应用规格
+
+    发布生产时，根据业务需求选择不同的性能配置：
+
+  - 常规应用：1核2G
+  - 大应用：2核4G
+  - 超大规格：3核8G
+  - 可以选择1-3个副本数
+
+- 【强制】资源监控
+
+    生产发布后，定期在codewave平台查看监控指标（运维中心>日志与监控>应用>查看监控>源监控）。
+
+    发现CPU使用率>90%和内存使用率>90%时及时排查问题，并看是否需要增加资源。
+
+- 【强制】接口监控
+
+    生产发布后，定期在codewave平台查看接口指标（运维中心-日志与监控-应用-查看监控-接口监控）
+
+    发现接口响应>2s,或接口错误率>10%及时排查问题。
+
+    如果开放接口请求频率很高（/rest开头的请求），可以单独起一个服务专门供开放接口调用，降低主应用压力。
+
+- 【强制】日志监控
+
+    生产发布后，定期在codewave平台查看Error日志（运维中心-日志与监控-应用-查看日志-日志级别-ERROR），发现异常日志及时排查问题。
+
+- 【强制】入参校验
+
+    在处理接口请求时，服务端需要进行入参校验和业务合法性校验。例如，如果用户在页面上看到编辑按钮，但在此期间数据已被删除，服务端在接收到编辑请求时需要先对数据的存在性进行验证。这意味着服务端需要检查请求中携带的数据标识符对应的数据是否存在，以及用户是否有权限进行编辑操作。这样可以确保操作的合法性，并向用户提供一致的体验。
+
+- 【强制】接口幂等性
+
+    在请求重复发送的情况下（网络波动、用户重复点击），接口也能够保持系统状态的一致性和正确性。即无论请求执行多少次，结果都是相同的。
+
+    > 说明：如果没有实现接口幂等性会有很严重的后果：支付接口，重复支付会导致多次扣钱 ；订单接口，同一个订单可能会多次创建。
+
+<div style="text-align: right;font-size: 14px;">
+    <span style="color: rgb(78, 110, 142);">创建人：</span>
+    <span style="color: rgb(118, 118, 118);">老王</span>
+    <span style="color: rgb(78, 110, 142);margin: 0 0 0 40px;">更新时间：</span>
+    <span style="color: rgb(118, 118, 118);">2025年03月03日</span>
+</div>