@routerhub/agent-rules 1.5.115 → 1.5.116
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.base.md +15 -0
- package/package.json +1 -1
- package/rules/global.md +15 -0
package/AGENTS.base.md
CHANGED
|
@@ -161,6 +161,21 @@
|
|
|
161
161
|
- 值传递优先,软删除用 `gorm.DeletedAt`(禁止 `*time.Time`)。
|
|
162
162
|
- 禁止无条件执行 GORM AutoMigrate,必须由开关控制,默认关闭。
|
|
163
163
|
|
|
164
|
+
## ⚠️ 数据存储选型铁律(Redis vs PostgreSQL)
|
|
165
|
+
|
|
166
|
+
- ⚠️ **能交给 Redis 的写入就交给 Redis,避免用 PostgreSQL 硬扛高频写入**(PG 面向持久化与复杂查询,高频写入场景性能差)。但 Redis 与 PG 不是同类存储,**必须区分场景使用,禁止无脑替代**。
|
|
167
|
+
- **Redis 优先的场景**(高频写、可容忍丢失、可重建的数据):
|
|
168
|
+
- 缓存(接口缓存、配置缓存、热点数据)
|
|
169
|
+
- 计数器、排行榜、PV/UV、点赞数等
|
|
170
|
+
- 限流(滑动窗口、令牌桶)、分布式锁
|
|
171
|
+
- 会话/Session、验证码等短时效数据(天然依赖 TTL 过期)
|
|
172
|
+
- **PostgreSQL 保留的场景**(不能丢、要按条件查、要事务):
|
|
173
|
+
- 业务主体数据(订单、用户、商品、账单等需要事务与持久化的数据)
|
|
174
|
+
- 需要复杂 SQL 查询、联表、报表统计的数据
|
|
175
|
+
- 需要长期保留、生命周期远大于缓存时长的数据
|
|
176
|
+
- ⚠️ **判定标准**:落库前先问三个问题——「这份数据丢了行不行?」「需不需要按条件查?」「需不需要事务?」。只要有一个答案是「需要/不行」,就必须用 PostgreSQL;三个都是「可以丢 / 不用查 / 不用事务」,才优先用 Redis。
|
|
177
|
+
- ⚠️ **Redis 只能做加速层,禁止作为唯一数据源承载不可重建的业务数据**——默认未开启持久化时进程重启数据即丢,Redis 中的数据必须能由上游(数据库/消息队列)重建。
|
|
178
|
+
|
|
164
179
|
## ⚠️ 数据库 DELETE 铁律(最高级别,所有写操作前必检)
|
|
165
180
|
|
|
166
181
|
- ⚠️ **DELETE 是数据库中唯一不可逆的写操作**(INSERT 可以删、UPDATE 可以回改,DELETE 执行后数据消失,只有备份能救)。因此 DELETE 的每一条都必须经过严格的「副作用范围检查」:
|
package/package.json
CHANGED
package/rules/global.md
CHANGED
|
@@ -161,6 +161,21 @@ name: "通用规则"
|
|
|
161
161
|
- 值传递优先,软删除用 `gorm.DeletedAt`(禁止 `*time.Time`)。
|
|
162
162
|
- 禁止无条件执行 GORM AutoMigrate,必须由开关控制,默认关闭。
|
|
163
163
|
|
|
164
|
+
## ⚠️ 数据存储选型铁律(Redis vs PostgreSQL)
|
|
165
|
+
|
|
166
|
+
- ⚠️ **能交给 Redis 的写入就交给 Redis,避免用 PostgreSQL 硬扛高频写入**(PG 面向持久化与复杂查询,高频写入场景性能差)。但 Redis 与 PG 不是同类存储,**必须区分场景使用,禁止无脑替代**。
|
|
167
|
+
- **Redis 优先的场景**(高频写、可容忍丢失、可重建的数据):
|
|
168
|
+
- 缓存(接口缓存、配置缓存、热点数据)
|
|
169
|
+
- 计数器、排行榜、PV/UV、点赞数等
|
|
170
|
+
- 限流(滑动窗口、令牌桶)、分布式锁
|
|
171
|
+
- 会话/Session、验证码等短时效数据(天然依赖 TTL 过期)
|
|
172
|
+
- **PostgreSQL 保留的场景**(不能丢、要按条件查、要事务):
|
|
173
|
+
- 业务主体数据(订单、用户、商品、账单等需要事务与持久化的数据)
|
|
174
|
+
- 需要复杂 SQL 查询、联表、报表统计的数据
|
|
175
|
+
- 需要长期保留、生命周期远大于缓存时长的数据
|
|
176
|
+
- ⚠️ **判定标准**:落库前先问三个问题——「这份数据丢了行不行?」「需不需要按条件查?」「需不需要事务?」。只要有一个答案是「需要/不行」,就必须用 PostgreSQL;三个都是「可以丢 / 不用查 / 不用事务」,才优先用 Redis。
|
|
177
|
+
- ⚠️ **Redis 只能做加速层,禁止作为唯一数据源承载不可重建的业务数据**——默认未开启持久化时进程重启数据即丢,Redis 中的数据必须能由上游(数据库/消息队列)重建。
|
|
178
|
+
|
|
164
179
|
## ⚠️ 数据库 DELETE 铁律(最高级别,所有写操作前必检)
|
|
165
180
|
|
|
166
181
|
- ⚠️ **DELETE 是数据库中唯一不可逆的写操作**(INSERT 可以删、UPDATE 可以回改,DELETE 执行后数据消失,只有备份能救)。因此 DELETE 的每一条都必须经过严格的「副作用范围检查」:
|