gitadmin/eden-basic
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

上传工程提示词

Browse Source
This commit is contained in:
gitadmin 2025-04-03 03:12:50 +00:00
parent 1a83edf82e
commit 3b8bae4357
4 changed files with 865 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

478
03工程提示词/Java编码规范.md Normal file
View File

@ -0,0 +1,478 @@
# JAVA 语言编码规范
## 4.1 命名规范
### 规则1.1(强制)
标识符由字母、数字、下划线和美元符（$）组成，不能包含@、%和空格等特殊字符，不能以下划线、数字或美元符号开始或结束，不能是Java关键字，区分大小写。
### 规则1.2(强制)
各种命名应使用正确的英文拼写和语法，避免拼音、混合拼写、不规范缩写、中文命名。
### 规则1.3(强制)
包名统一小写，点分隔符间一个自然语义单词，词意从大到小，前缀顶级域名，项目包名以com.psbc.开头。
### 规则1.4(强制)
类名使用UpperCamelCase命名方式，简洁且富于描述。
### 规则1.5(建议)
抽象类命名建议Abstract开头，异常类Exception结尾，测试类Test结尾，设计模式体现于类名。
### 规则1.6(强制)
方法名使用lowerCamelCase命名方式。
### 规则1.7(强制)
常量命名全大写，单词间下划线隔开，语义完整清楚。
### 规则1.8(建议)
布尔类型实例变量命名不使用is前缀。
### 规则1.9(强制)
参数名、实例变量、局部变量使用lowerCamelCase命名方式。
### 规则1.10(强制)
类型与中括号紧挨表示数组。
### 规则1.11(强制)
避免子父类成员变量、不同代码块局部变量相同命名。
### 规则1.12(建议)
自定义编程元素命名尽量完整单词组合。
### 规则1.13(建议)
常量、变量命名表示类型名词放词尾。
### 规则1.14(建议)
接口类方法、属性不加修饰符号，简洁并加Javadoc注释，接口少定义变量。
### 规则1.15(强制)
Service和DAO类基于SOA理念，暴露服务是接口，内部实现类用Impl后缀。
### 规则1.16(建议)
形容词接口名用形容词，如–able结尾。
### 规则1.17(建议)
枚举类名带Enum后缀，成员名称全大写，单词间下划线隔开。
### 规则1.18(建议)
a) Service/DAO层方法命名：
1）获取单个对象用get前缀；
2）获取多个对象用list前缀，复数结尾；
3）获取统计值用count前缀；
4）插入用save/insert前缀；
5）删除用remove/delete前缀；
6）修改用update前缀。
b) 领域模型命名：
1）领域对象以xxxDO/DTO/VO命名；
2）避免以POJO结尾实体对象或值对象命名。
## 4.2 格式规范
### 规则2.1(强制)
源文件编码UTF-8，Unix换行符。
### 规则2.2(建议)
除注释外，方法签名等总行数不超过80行。
### 规则2.3(强制)
类文件组成部分顺序：文件头注释、包引入、类声明、常量、变量、构造函数、方法。
### 规则2.4(建议)
多个构造函数或同名方法应顺序在一起。
### 规则2.5(建议)
方法按功能而非作用域或访问权限分组。
### 规则2.6(强制)
引用类时禁止用*引入包全部类，避免无用、重复引用，不import java.lang和同包类。
### 规则2.7(强制)
Java关键字正确顺序：public、protected、private、abstract、static、final、transient、volatile、synchronized、native。
### 规则2.8(建议)
避免多余关键字，接口方法属性不加修饰符号。
### 规则2.9(强制)
每行至多一条语句。
### 规则2.10(强制)
大括号使用约定：
a）左大括号前不换行；
b）左大括号后换行；
c）右大括号前换行；
d）右大括号后有else等代码不换行，终止后必须换行；
e）大括号内为空，简洁写成{}，不换行。
### 规则2.11(建议)
缩进采用4个空格，多行变量声明赋值不强制等号对齐，tab设为4空格宽度。
### 规则2.12(建议)
单行字符数不超过120，换行原则：
a）第二行相对第一行缩进4空格，第三行起不再缩进；
b）运算符与下文换行；
c）点符号与下文换行；
d）方法调用参数多需换行时，在逗号后换行；
e）括号前不换行。
### 规则2.13(建议)
用空行分隔逻辑相关代码段，提高可读性，不插入多个空行。
## 4.3 注释规范
### 规则3.1(建议)
类、属性、方法注释使用Javadoc格式。
### 规则3.2(强制)
公共API代码必须编写JavaDoc注释，类、属性、方法、参数、返回值、异常全部注释。
## 4.4 常量变量
### 规则4.1(建议)
避免使用魔法数，应定义为常量。
### 规则4.2(强制)
长整型常量后使用大写字母“L”。
### 规则4.3(建议)
浮点数类型数值后缀统一为大写D或F。
### 规则4.4(建议)
按功能或模块归类常量。
### 规则4.5(建议)
常量复用层次分为五层：跨应用、应用内、子工程内、包内、类内。
### 规则4.6(建议)
变量值在固定范围变化时用enum类型。
### 规则4.7(强制)
每行只声明一个变量。
### 规则4.8(建议)
局部变量声明时初始化。
### 规则4.9(强制)
避免一个语句中给多个变量赋相同值，不用内嵌赋值运算符。
### 规则4.10(强制)
避免局部变量覆盖上一级变量。
### 规则4.11(强制)
数组类型变量声明采用数据类型[]的方式。
## 4.5 控制语句
### 规则5.1(强制)
switch括号内为String且为外部参数时，先进行null判断。
### 规则5.2(强制)
每个switch语句包含default分支，且default在最后。
### 规则5.3(强制)
if/else/for/while/do语句中必须使用大括号。
### 规则5.4(建议)
避免不可达的else if和else分支。
### 规则5.5(强制)
条件表达式尽量简化。
### 规则5.6(建议)
返回表达式尽量简化。
### 规则5.7(建议)
避免在循环中重复执行相同内容。
### 规则5.8(建议)
慎用非短路逻辑运算符。
### 规则5.9(建议)
含多种运算符的表达式中使用圆括号。
### 规则5.10(建议)
三元运算符前的表达式需加圆括号。
### 规则5.11(建议)
复杂条件判断结果赋值给布尔变量。
## 4.6 面向对象
### 规则6.1(强制)
禁止用类的实例对象引用访问静态变量或方法。
### 规则6.2(强制)
覆写方法必须加@Override注解。
### 规则6.3(强制)
覆写equals必须覆写hashCode。
### 规则6.4(建议)
过时接口或方法加@Deprecated注解。
### 规则6.5(建议)
避免使用过时类或方法。
### 规则6.6(建议)
慎用可变参数编程。
### 规则6.7(建议)
用常量或确定有值的对象调用equals。
### 规则6.8(建议)
参数个数相同的方法重载时，避免用自动转换类型，建议用不同方法名。
### 规则6.9(建议)
使用final关键字的情况：
a）不允许继承的类；
b）不允许修改引用的域对象；
c）不允许重写的方法；
d）不允许重新赋值的局部变量；
e）避免重复使用变量。
### 规则6.10(建议)
慎用Object的clone方法。
### 规则6.11(强制)
类成员变量访问控制从严。
### 规则6.12(建议)
类方法访问控制从严。
### 规则6.13(强制)
构造方法中避免处理业务逻辑，初始化逻辑放init方法。
### 规则6.14(强制)
RPC方法返回值和参数用包装类型。
### 规则6.15(建议)
局部变量用基本类型。
### 规则6.16(建议)
POJO类不设定属性默认值。
### 规则6.17(强制)
POJO类必须写toString方法。
### 规则6.18(强制)
POJO类禁止同时存在isXxx和getXxx方法。
### 规则6.19(建议)
setter中参数名与成员变量名一致，this.成员名=参数名。getter/setter中不加业务逻辑。
### 规则6.20(强制)
序列化类新增属性时不修改serialVersionUID，不兼容升级时修改。
## 4.7 数值计算
### 规则7.1(强制)
比较字符串用equals，不用==或!=。
### 规则7.2(强制)
避免自动类型转换导致溢出或精度丢失。
### 规则7.3(建议)
避免高精度转低精度溢出。
### 规则7.4(强制)
禁止用BigDecimal(double)构造，用String构造或valueOf。
### 规则7.5(强制)
精确计算用BigDecimal，不用浮点数。
### 规则7.6(强制)
与NaN比较用isNaN()，不用==或!=。
### 规则7.7(强制)
自增自减运算符使用要产生实际影响。
### 规则7.8(强制)
BigDecimal比较用compareTo，不用equals。
### 规则7.9(强制)
SimpleDateFormat非线程安全，不用在并发环境。JDK8及以上用DateTimeFormatter。
### 规则7.10(强制)
日期格式化Pattern统一规范。
### 规则7.11(建议)
三目运算符注意类型对齐可能引发空指针。
## 4.8 集合规范
### 规则8.1(建议)
慎用ArrayList.subList。
### 规则8.2(建议)
慎用Arrays.asList。
### 规则8.3(强制)
集合转数组用toArray(T[] array)，传入长度为0的空数组。
### 规则8.4(强制)
禁止集合中添加自身。
### 规则8.5(强制)
foreach循环中不做remove/add操作，用Iterator。
### 规则8.6(建议)
参照常用Map集合K/V存储null情况。
### 规则8.7(建议)
合理利用集合的有序性和稳定性。
### 规则8.8(强制)
集合明确泛型。
### 规则8.9(建议)
判断集合元素是否为空用isEmpty，不用size()==0。
### 规则8.10(强制)
toMap()方法必须用带mergeFunction的。
### 规则8.11(强制)
toMap()方法中value为NULL时处理。
### 规则8.12(强制)
不可对keySet()/values()/entrySet()返回集合做增删。
### 规则8.13(强制)
排序时Comparator要满足三个条件。
## 4.9 线程安全
### 规则9.1(建议)
单例获取保证线程安全，推荐饿汉模式。
### 规则9.2(建议)
并发访问的单例禁止有状态成员变量。
### 规则9.3(建议)
创建线程或线程池指定有意义名称。
### 规则9.4(建议)
多个资源加锁保持一致顺序。
### 规则9.5(强制)
CountDownLatch使用确保countDown被执行。
### 规则9.6(强制)
锁在finally中释放。
### 规则9.7(强制)
同步代码中不用public属性。
### 规则9.8(强制)
占用锁时不调用Thread.sleep。
### 规则9.9(建议)
并发场景用线程安全集合。
### 规则9.10(强制)
线程资源通过线程池提供，不显式创建。
### 规则9.11(建议)
线程池用ThreadPoolExecutor，不用Executors。
### 规则9.12(建议)
高并发避免用“等于”判断，用区间判断。
## 4.10 异常处理
### 规则10.1(强制)
可通过预检查避免的RuntimeException不捕获。
### 规则10.2(建议)
不用异常做流程控制。
### 规则10.3(建议)
finally中不使用return。
### 规则10.4(强制)
非稳定代码catch区分异常类型。
### 规则10.5(强制)
捕获异常要处理，不抛弃，最外层业务使用者处理异常。
### 规则10.6(强制)
try在事务代码中，catch后手动回滚事务。
### 规则10.7(强制)
finally中关闭资源，JDK7+用try-with-resources。
### 规则10.8(建议)
捕获与抛出异常类型匹配。
### 规则10.9(建议)
捕获异常区分Exception和Error。
## 4.11 日志规范
### 规则11.1(强制)
应用用日志框架（SLF4J）API，不用直接用Log4j、Logback API。
### 规则11.2(强制)
禁止用System.out.print等方法，用标准日志框架。
### 规则11.3(建议)
日志用占位符，不用“+”拼接。
### 规则11.4(建议)
日志级别分为FATAL、ERROR、WARN、INFO、DEBUG，各级别使用建议。
### 规则11.5(建议)
info/debug日志进行开关判断。
### 规则11.6(强制)
日志中用户敏感信息脱敏。
### 规则11.7(建议)
日志打印参数中避免复杂表达式。
## 4.12 性能相关
### 规则13.1(建议)
同步调用优先用无锁数据结构，锁代码块尽可能小。
### 规则13.2(建议)
避免频繁创建可复用资源。
### 规则13.3(建议)
避免创建不必要的对象。
### 规则13.4(建议)
避免变量重复计算。
### 规则13.5(建议)
try/catch放在循环外层。
### 规则13.6(建议)
池化重量级资源。
### 规则13.7(建议)
遍历Map用entrySet，JDK8+用Map.foreach。
### 规则13.8(建议)
用Set去重，不用List的contains。
### 规则13.9(建议)
慎用递归，必须时保证出口可执行。
### 规则13.10(建议)
用观察者模式替换无限轮询。
### 规则13.11(建议)
缓存不常变化数据。
### 规则13.12(建议)
字符串拼接用StringBuilder或StringBuffer。
### 规则13.13(建议)
数组拷贝用System.arraycopy。
### 规则13.14(建议)
合理使用单例。
### 规则13.15(建议)
避免随意用静态变量。
### 规则13.16(建议)
未发生线程安全时用HashMap、ArrayList。
### 规则13.17(建议)
避免用二维数组。
### 规则13.18(建议)
合理使用线性表和链表。
### 规则13.19(建议)
避免非常大的内存分配。
### 规则13.20(建议)
正则表达式编译后复用。

178
03工程提示词/SQL语言编码规则.md Normal file
View File

@ -0,0 +1,178 @@
## 4.1 SQL 编写
- **规则 1（建议）**：在编写 SQL 语句时，每行建议不要超过 80 字符，基于列对齐原则，应采用下一行缩进。
- **规则 2（建议）**：使用两个空格表示缩进，同层次的语句应保持纵向对齐。
- **规则 3（建议）**：建议使用预编译 SQL，PreparedStatement，预编译语句既可以提高性能，又可以有效防止 SQL 注入。
## 4.2 查询语句规范
- **规则 4（建议）**：尽量避免使用 COUNT(列名)来替代 COUNT(*)，COUNT(*)是 SQL92 定义的标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。COUNT(*)会统计值为 NULL 的行，而 COUNT(列名)不会统计此列为 NULL 值的行。
- **规则 5（强制）**：禁止使用 SELECT * 操作，所有查询操作必须明确指定列名，避免查询过多无用的列。
- **规则 6（强制）**：禁止使用不带 WHERE 条件的 DELETE、UPDATE 语句操作全表，且要使用索引列操作，避免锁表。对于需要客户端传参来创建 SQL 的场景，必须要对参数进行非空判断，确保 SQL 含有 WHERE 条件。
- **规则 7（强制）**：对于同时使用包括 AND 和 OR 的复合查询语句，必须增加必要的括号，以保证查询优先级的准确性。
- **规则 8（建议）**：使用 IN 查询代替 OR。如使用 IN 查询，需要控制 IN 后边的集合元素数量，不宜过多，需控制在 1000 个之内。
- **规则 9（建议）**：建议以合理的方式使用分页查询，使用 LIMIT、OFFSET 查询时，页数越大，需要扫描的数据量越大，查询就越慢。
- **规则 10（建议）**：分库分表场景下，尽量避免进行聚合查询，建议 SQL 语句均加上分片键。若
有聚合查询的需求，可单独通过聚合库实现。
## 4.3 索引规范
- **规则 11（强制）**：禁止隐式类型转换，对于字段是字符串类型的，查询必须加引号。
- **规则 12（强制）**：禁止索引列使用函数运算或者使用表达式，否则会导致索引失效。
- **规则 13（强制）**：索引列使用 LIKE 模糊查询时，禁止使用%前导查询。
- **规则 14（强制）**：联合索引查询要遵守最左匹配原则。
- **规则 15（建议）**：尽量避免对索引列使用负向查询，例如 NOT IN、!=、NOT LIKE、<>，否则可能导致索引失效。
- **规则 16（建议）**：合理使用覆盖索引，可减少 IO 次数，有效避免回表查询引起的性能问题。
- **规则 17（建议）**：尽量避免全表扫描，需在生产环境执行的 SQL 原则上都应被索引，如 UPDATE、DELETE 的 WHERE 条件列、ORDER BY、GROUP BY、DISTINCT 字段、多表 JOIN 字段。
## 4.4 联结表规范
- **规则 18（强制）**：JOIN 联查时必须使用索引列联查，且索引列的类型要保持一致。
- **规则 19（建议）**：在进行 JOIN 联查时，联查的表数量尽量控制在 3 张表以内，过多的表联查会严重影响性能。
- **规则 20（建议）**：在进行多表查询时，要用 JOIN 代替子查询，子查询的性能相比于 JOIN 联查较差。
- **规则 21（建议）**：JOIN 联查时，如果两个表的编码不一致，也有可能导致索引失效，因此要尽量确保联查表的编码方式相同。
## 4.5 分组与排序
- **规则 22（建议）**：对查询结果顺序无要求时，不要使用 ORDER BY 进行排序，在需要排序的场景下尽量避免使用非索引列进行 ORDER BY 排序。
- **规则 23（建议）**：避免冗余的排序，使用 GROUP BY 时，默认会进行排序，如果不需要排序，可以使用 ORDER BY NULL。
- **规则 24（建议）**：避免使用 DISTINCT，可以使用 GROUP BY 代替，如果使用 DISTINCT 获取多列名称时，会对多列进行重复行去重，而不是单独对某一列去重。
- **规则 25（建议）**：由于 UNION 默认会对结果集进行排序、去重，因此在性能上要比 UNION ALL 差一些。如果结果集没有重复行或者不需要进行重复行合并，建议使用 UNION ALL。
## 4.6 事务处理
- **规则 26（建议）**：避免大事务（执行时间较长的事务），如耗时的操作、一次性操作的数据过多，数据库单事务提交的明细数量原则上不应超过 5000 笔。大事务可能会导致数据库出现大量的阻塞和锁等待的现象，同时在并发较高的场景下，会造成客户端连接池耗尽、主从延迟等问题。建议将大事务拆分成小事务，分多次操作。
- **规则 27（强制）**：禁止使用 INSERT INTO B SELECT * FROM A 语句，该语句当执行异常时会出现数据不一致的问题，同时可能会对原表 A 加表锁。
- **规则 28（建议）**：事务操作，注意获取资源的顺序，避免出现死锁的情况。
## 4.7 其他
- **规则 29（建议）**：获取大量数据时，建议分批次获取数据，每次数据量应小于 500 条，结果集应小于 1M。
- **规则 30（建议）**：大批量更新数据时，索引维护成本很高，因此大批量数据更新建议拆分出小粒度，分多次更新。
- **规则 31（强制）**：当某一列的值全是 NULL 时，count(col)的返回结果为 0，但 sum(col)的返回结果为 NULL，因此使用 sum()时要注意空指针异常问题。
- **规则 32（强制）**：禁止使用外键与级联更新，可通过应用程序来约束。级联更新是强阻塞，存在数据库更新风暴的风险，使用数据库外键可能出现死锁，同时影响数据库的插入速度。
- **规则 33（建议）**：SQL 中避免出现 random()、sysdate()等不确定结果的函数。
- **规则 34（强制）**：必须使用 IS NULL 来判断是否是 NULL 值。
- **规则 35（建议）**：谨慎使用存储过程，存储过程难以调试和扩展，不具有移植性。
# 6 SQL 语句编写规则
## 6.1 查询语句索引使用原则（建议）
- 查询列、排序列尽量使用索引列并与其次序保持一致。
- 应避免在 WHERE 子句中对索引列使用 IS NULL，IS NOT NULL。
- 应避免在 WHERE 子句中对索引列使用 LIKE ’%xxx%’、LIKE ’%xxx’，可以使用 LIKE ‘xxx%’。
- 对于复合索引，WHERE 子句中包含索引的第一列查询效率最高。
- 表结构中字段定义的数据类型与应用程序中的定义保持一致，避免隐式/显式转换情况发生。
- WHERE 子句中表字段尽量不参加计算。
- 建议使用||连接字符串，不使用 CONCAT 函数，CONCAT 函数不走索引。
- WHERE 子句索引列上尽量不用 NOT、OR、!=、<>。
## 6.2 查询语句排序原则（建议）
- 应尽量减少 ORDER BY 排序操作。
- 如果一定要排序，应尽量建立在索引列上,且 NULLS FIRST 或 NULLS LAST 与索引 NULLS FIRST 或 NULLS LAST 一致。
- 如果业务规则允许结果集不需要唯一确定或者各子查询的结果集没有重复，应使用 UNION ALL 替代 UNION。
- ORDER BY 明确指定列名。
## 6.3 使用 case when 减少数据库访问次数（建议）
- 合并一条语句，减少对数据库的多次访问。
## 6.4 使用 EXIST 代替 IN 语句（建议）
- 使用 EXIST 代替 IN 可能会提高性能，但并非所有情况都适用。具体要依据测试结果而定。
## 6.5 使用 NOT EXIST 或外连接代替 NOT IN 语句（建议）
- 使用 NOT EXIST 或外连接代替 NOT IN 可能会提高性能，但并非所有情况都适用。具体要依据测试结果而定。
- 注意 NOT IN 与 NOT EXISTS 不一定相等，需注意对空值的处理。
## 6.6 使用表连接替代 EXIST 子句（建议）
- 一般情况下，使用表连接替代 EXIST 子句可提高性能。
## 6.7 使用 EXIST 子句替代 DISTINCT 子句。（建议）
- 一般情况下，使用 EXIST 子句替代 DISTINCT 子句可提高性能。
## 6.8 慎用 with 子查询（建议）
- WITH语句（Common Table Expressions） CTEs 通用表达式，定义只在查询中存在临时表，占用一定的资源。
## 6.9 日期格式明确化 （建议）
- 日期格式应明确化。
## 6.10 列表查询（建议）
- 应当控制前台列表查询输出项个数，不要输出太多字段，需要查看更多字段时，从前台列表中选择单个记录，再显示详细信息，列表查询输出项所有字段所涉及表，建议控制在 3 个表以内，除 SELECT 字段列表内所涉及表外，其它表采用动态 SQL 方式。
## 6.11 增加查询过滤条件（建议）
- 建议添加时间、机构维度的 WHERE 过滤条件，例如：流水类数据、消息提醒等，提高查询性能。
- 在不改变查询结果的前提下，增加查询条件中的索引字段。没有索引字段的建议选择性大的字段放前面。
## 6.12 避免用*返回查询结果（强制）
- 任何地方都不要使用 SELECT * FROM t ,用具体的字段列表代表*，不要返回用不到的任何字段，另外表结构发生变化也容易出现问题。
## 6.13 避免使用 delete 全表（强制）
- 不要使用 DELETE 全表，性能很差，请使用 TRUNCATE 代替。
## 6.14 null 值的处理（强制）
- 注意 NULL 值的处理，对于数值计算，使用 COALESCE(value [, ...])函数为 NULL 值提供默认值 0。
## 6.15 表别名和列别名的命名（强制）
- 表别名，列别名命名时，尽量按照原表名和列名的省略缩写形式，保持 SQL 的可读性。
## 6.16 插入列明确指定（强制）
- 插入列时应明确指定列名。
## 6.17 查询事务（强制）
- 对于基于查询结果判断后续操作的，应在同一事务内，且查询使用 FOR UPDATE 进行查询加锁。
- 在查询事务中，应避免写复杂 SQL，可将复杂 SQL 拆分成多个小 SQL 来完成对应查询。
## 6.18 批量插入（建议）
- 批量插入可以显著减少与数据库的通信开销，提高数据库性能并降低事务处理的复杂性，INSERT INTO ... VALUES 语句可以一次插入多行数据。采用批量插入 SQL 语句时，单次建议不超过 1000 条。
## 6.19 多表联合查询（建议）
- 多表查询建议使用 JOIN 关键字进行多表关联查询，而不是使用子查询，要根据需求选择 JOIN 方式，并确保所有连接操作都有明确的连接条件，连接条件中的列有适当的索引，尽量控制关联的表数量在 3 个以内，同时建议将记录数较少的表放在前面，可以减少中间结果集的大小，从而提高查询效率。
- 对于多表关联查询时返回大量数据的情况，应通过定义合适的查询条件尽量控制返回结果集的大小，只获取需要的数据。
## 6.20 分页查询（建议）
- 应该尽量避免向客户端返回大数据量，若因业务需要获取大量数据时，建议不要一次性全量获取，而是分批次获取数据。每次获取的数据量应小于 500 条，结果集应小于 1M。
- 建议使用合理的分页方式以提高分页效率，分页时尽量避免直接使用 LIMIT OFFSET，否则可能数据越靠后，查询越慢，可以考虑使用游标分页或基于主键的分页，或者加上一些 WHERE 限制条件进行分页查询。
## 6.21 COMMENT 格式规范
### 6.21.1 表 COMMENT（建议）
- 数据库表应采用 Comment 进行注释。在注释中应明确表的中文名称。
- 语法：COMMENT ON TABLE table_name IS ‘string_literal’;
- string_literal 格式：表中文名
- string_literal 为必填项。
### 6.21.2 字段 COMMENT（建议）
- 数据库表的字段应采用Comment进行注释。在注释中应明确字段的中文名称、数据标准、数据质量等信息。
- 语法：COMMENT ON COLUMN table_name.column_name IS‘string_literal’;
- string_literal 格式：名称：字段中文名。标准：数据项编号|不贯标原因。质量：数据质量规则编号|无。
- string_literal 为必填项，包括字段名称、数据标准、数据质量三个必填部分，分别以“名称：”、“标准：”、“质量：”开头，以“。”结尾。其中标准部分，若已贯标，请填写引用的企业级数据字典数据项编号；若未贯标，请填写不贯标原因。质量部分，若匹配了企业级数据质量规则，请填写数据质量规则编号，多条规则间采用半角“,”分隔；若未匹配，请填写“无”。

153
03工程提示词/工程生成提示词.md Normal file
View File

@ -0,0 +1,153 @@
# 工程生成规范
### 角色定位
你是专业软件工程师，结合Claude-3.7特性完成Vue前端和Java后端开发。
### 输入信息
- 《Sql表结构.sql》：含系统现有表结构，确保代码与之兼容。
- 《sql初始化脚本.sql》：大模型依《需求规范文档.md》创建的新表。
- 《SQL语言编码规则.md》：：此文档是SQL编码的核心准则，在编写任何SQL语句时，必须严格遵守其中的所有规则，特别是“强制性规则”，具有最高优先级。
- 《Java编码规范.md》：此文档是Java编码的核心准则，在编写Java代码时，必须严格遵守其中的所有规则，特别是“强制性规则”，具有最高优先级。
- 《需求规范文档.md》：数据建模和工程生成的核心依据，详细描述了系统的功能需求、业务规则、操作权限等信息。在进行数据建模和工程生成时，应仔细研读此文档，确保生成的代码符合文档中的要求。。
## 技术栈
- Java 8：类库丰富，性能稳定，Lambda和Stream API提高开发效率。
- Spring Boot 2.7.18：简化Spring开发，提供自动配置和嵌入式服务器。
- MyBatis 3.5.9：持久层框架，支持定制SQL和高级映射。
- Vue 2.6：轻量级前端框架，响应式数据绑定和组件化开发。
- PostgreSQL 14.7：开源关系型数据库，支持复杂查询和高并发。
- Redis 7.0.15：键值对数据库，用于缓存和会话管理。
- Druid 1.2.8：数据库连接池，提供监控和防御SQL注入功能。
- ShardingSphere 5.4.1：分布式数据库中间件，支持数据分片和读写分离。
## 架构规范
### 分层架构
分层架构的设计理念是将不同功能模块分离，提高代码的可维护性和可扩展性。以下是各层的详细说明：
1. **实体层**：
- 继承数据建模结果中的字段定义：确保实体类与数据库表结构一致，方便数据的映射和操作。
- 包含JSR303校验注解（@NotBlank/@Pattern）：对实体类的字段进行数据校验，提高数据的准确性和完整性。
- 审计字段：@CreateBy/@LastModifiedDate：记录数据的创建和修改信息，方便数据的追溯和管理。
2. **Mapper层**：负责数据库操作的接口层，将Java方法与SQL语句进行映射。
- XML文件需包含<sql id="Base_Column_List">：定义基础列名，提高SQL语句的复用性。
- 使用注解对mapper方法入参校验：确保传入参数的合法性，避免SQL注入等安全问题。
- 分页查询使用PageHelper插件：简化分页查询的实现，提高开发效率。
- 多园区数据隔离通过@TenantId实现：实现不同园区数据的隔离，提高数据的安全性。
- 多表关联需使用@Results/@ResultMap：处理多表关联查询的结果映射，提高数据的准确性。
- 复杂查询需使用@SelectProvider：灵活处理复杂查询，提高查询的性能。
- 多表关联批量更新需使用@UpdateProvider：提高多表关联批量更新的效率。
- 多表关联批量删除需使用@DeleteProvider：提高多表关联批量删除的效率。
- 外键字段需使用@TableField(exist=false)标记：避免在实体类中映射外键字段，减少数据冗余。
3. **Service层**：处理业务逻辑的核心层，调用Mapper层的方法完成具体业务操作。
- 业务方法需@Transactional：确保业务操作的原子性，保证数据的一致性。
- 使用策略模式实现业务扩展点：提高代码的可扩展性，方便业务的扩展和维护。
- 异常处理统一在@ServiceAdvice中处理：集中处理API层的异常，提高代码的可维护性。
4. **Controller层**：负责接收客户端请求，调用Service层的方法处理请求，并返回响应结果。
- 统一返回Result<T>包装类：规范接口返回数据的格式，提高接口的可读性和可维护性。
- API路径遵循/v1/模块名/功能名：遵循RESTful API设计原则，提高接口的规范性和可维护性。
- 使用@Validated进行参数校验：确保传入参数的合法性，避免因参数错误导致的业务异常。
- 分页查询使用Pageable接口：方便实现分页查询功能，提高用户体验。
5. **Api层**：对外提供服务接口，将业务逻辑封装成API供外部系统调用。
- 统一返回Result<T>包装类
- API路径遵循/v1/模块名/功能名
- 使用@Validated进行参数校验
### Vue架构
Vue架构采用组件化开发的思想，提高代码的可复用性和可维护性。以下是组件规范和接口调用的详细说明：
1. **组件规范**：
- 使用Composition API写法：提高代码的逻辑复用性和可维护性，方便组件的组合和拆分。
- 状态管理采用Pinia：轻量级的状态管理库，具有响应式数据和模块化设计的特点，方便管理组件间的状态。
- 全局组件存放在/src/components/common：将全局组件统一管理，提高组件的复用性。
2. **接口调用**：负责与后端API进行数据交互，获取和更新数据。
- axios实例配置请求拦截器：在请求发送前进行统一处理，如添加请求头、处理请求参数等。
- API模块按功能域划分：将不同功能的API接口进行分组管理，提高代码的可维护性。
- 错误处理统一在响应拦截器：集中处理接口调用的错误，提高用户体验。
## 设计要求
### UI/UX
- 全屏响应式，适配不同设备。
- 支持亮色和夜间模式，用CSS变量和JavaScript实现切换。
- 现代化、简洁界面，用清晰字体和图标。
- 色彩丰富且和谐，可用搭配工具选色。
- 流畅交互动画，如按钮点击动画。
- 按钮等地方添加图标，确保与文字一致。
- 参考苹果官网设计美学。
### 后端
- 遵循RESTful，仅用POST方法。
- 采用合理的软件设计模式（如策略模式、工厂模式等）保证模块功能可扩展性和可维护性。
- Controller和Mapper层实现错误处理和输入验证，确保接口的健壮性。
- 用线程池处理异步操作，提高系统的性能和响应速度。
- 关键步骤添加详细注释，提高代码的可读性和可维护性。
- 确保Java实体类字段和数据库表结构的含义一致。
- 注意代码注释和规范。
- 确保API接口正确安全。
- 注意异常处理和日志记录：在代码中添加异常处理和日志记录逻辑，确保系统的稳定性和可维护性。
- 代码质量：可读性高，遵循SOLID原则，性能达标，可扩展性强，可测试性好，可部署性好，可复用性高。
• 可读性：使用有意义的命名，保持方法长度≤50行
• 可维护性：遵循SOLID原则，圈复杂度≤5
• 性能：查询响应时间≤500ms，JVM内存占用≤2GB
• 可扩展性：使用策略模式实现核心业务扩展点
• 可测试性：单元测试覆盖率≥90%，包含边界条件测试
• 可部署性：确保代码可以在不同的环境中正常部署和运行。
• 可复用性：编写可复用的代码，提高代码的开发效率和可维护性。
### 总结思考要求
1. **规范违背情况**：在建模过程中，若发现有违背《SQL语言编码规则.md》、《Java编码规范.md》的规则或要求的地方，请详细指出，并说明原因和提供具体的改进建议。
2. **需求实现情况统计**：明确指出实现了《需求规范文档.md》哪些功能，还有哪些功能没有实现。
3. **设计原则与特点**：详细阐述设计遵循的原则和设计特点，同时深入分析结果存在的不足，并提出切实可行的改进措施。例如，分析系统的架构设计是否符合分层架构的原则，是否存在性能瓶颈等问题，并提出相应的改进建议。
## 执行流程
1. 在03工程目录执行`mvn archetype:generate`创建工程。
2. 用`npm create vue@latest`初始化前端工程。
3. 暂不生成用户权限管理代码。
4. 开发顺序：Entity -> Mapper -> Service -> Controller -> Api -> Vue页面。
5. 输出Api层接口文档，生成UT单元测试用例。
6. 启动前后端服务，验证接口功能，确认是否满足需求文档的要求。
7. 自动执行：“auto - run”模式，成功则继续，失败则尝试不同方法，多次失败暂停。执行中记录日志。
## 环境配置
```yaml
spring:
datasource:
url: jdbc:postgresql://1.14.121.39:5432/edendb
username: edenuser
password: edenpswd
redis:
host: 1.14.121.39
password: edenpswd
```
## 代码生成模板
```java
// 实体类示例
@Getter
@Setter
public class User {
@NotBlank(message="用户名不能为空")
private String username;
@JsonFormat(pattern="yyyy-MM-dd HH:mm:ss")
private LocalDateTime createTime;
}
// Mapper示例
@SelectProvider(type = UserSqlProvider.class, method = "queryByCondition")
Page<User> selectByCondition(@Param("condition") UserQuery condition);
// Service示例
@Transactional
public PageInfo<User> pagingQuery(UserQuery query) {
PageHelper.startPage(query.getPageNum(), query.getPageSize());
return new PageInfo<>(userMapper.selectByCondition(query));
}
// Controller示例
@RestController
@RequestMapping("/v1/user")
public class UserController {
@PostMapping("/create")
public Result<Long> createUser(@Valid @RequestBody UserCreateDTO dto) {
return Result.success(userService.create(dto));
}
}
```

56
03工程提示词/需求规范文档.md Normal file
View File

@ -0,0 +1,56 @@
# 1.功能描述
# 2.业务规则
# 3.操作权限及授权
# 4.功能场景描述
## 4.1界面描述（输入和输出）
<font color='red'>备注：使用表格或者前端页面进行描述</font>
## 4.2业务流程
<font color='red'>**备注：**把图片格式的流程图转换成Mermaid语法描述</font>
```mermaid
graph TD
A[开始] --> B[发送取文件通知消息]
B --> C[接收响应信息]
C --> D[结束]
```
## 4.3处理过程
<font color='red'>备注：处理过程基于流程图来描述。</font>
## 4.4异常处理
# 5.外部接口
| 外系统名称 | 接口名称 | 说明 |
| ---------- | -------- | ---- |
| Comm-mid | 文件下载 | |
| 文件上传 | | |
# 6.特殊事项
| 测试要点 | 要点说明 |
| ----------------- | ------------------------------------------------------------ |
| 文件上传 | 文件成功上传，请求系统收到正确的消息通知 |
| 文件下载 | 文件下载成功，请求系统收到正确文件下载内容 |
| 文件下载失败 | 返回comm-mid的响应结果 |
| 文件上传失败 | 返回comm-mid的响应结果 |
| 文件上传-文件监控 | 查询日志监控是否推送成功或者失败，根据流水号在监控查询是否存在 |