MatchRPG Unlimited Constants DB Cap Strategy¶
概念概覽
企劃慣例：99999999999 = 遊戲設計上無上限¶
核心知識¶
企劃慣例：99999999999 = 遊戲設計上無上限¶
常數表（FixedValueConfig.xlsx）中填入 99999999999 是企劃表達「遊戲設計上無上限」的慣例語義，不是真實數字。伺服器不能照單全收，否則可能造成：
- DB 整數欄位溢出
- 不合理的資源累積
- 前端顯示異常
Cap 策略（正確做法）¶
// 讀取常數表值
constantsValue := getConfig("staminaMax") // 可能是 99999999999
// cap 在設計文件規定的 DB 保護上限
const DB_PROTECT_CAP = 2000 // 設計文件規定
actualMax := min(constantsValue, DB_PROTECT_CAP)
注意：這裡的
2000是設計文件規定的 DB 保護上限，hardcode 在伺服器端是合理的（有文件依據），不需要每次從常數表讀取。
為何不用 min(fallback, constants_value)¶
因為常數表的大數值是**設計語義**（表示無上限），不是真實數字。正確做法是：
1. 理解語義（99999999999 = 無上限）
2. 在伺服器端根據設計文件 cap 到安全上限
3. 不採用 min(fallback, constants_value)，因為這把設計語義當成真實數字來比較
經驗教訓¶
-
常數表的大數值是設計語義，不是真實數字，必須在伺服器端根據設計文件 cap
-
DB 保護上限 hardcode 在伺服器端是合理的，需有設計文件依據
-
不知道「99999999999 = 設計無上限」這個慣例，很容易直接存入 DB 造成整數溢出
常見陷阱¶
-
直接將常數表的 99999999999 存入 DB，造成整數溢出
-
使用 min(fallback, constants_value) 誤把設計語義當真實數字比較
-
未建立「無上限常數處理規範」，導致不同開發者處理方式不一致
最佳實踐¶
-
建立規範：常數表填 99999999999 = 設計無上限，伺服器端必須 cap 在設計文件規定的安全上限
-
DB 保護上限應有明確的設計文件引用，不能只是隨意 hardcode
-
讀取常數表後，先判斷是否為「無上限語義值」，再決定 cap 策略
相關概念¶
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-04-02 | 45b7e5f8-50d6-4529-afa9-e872dd553db2 | 確立「常數表大數 = 設計無上限，伺服器端需 cap」的規範，防止直接存入 DB 造成整數溢出 |