合数的阶乘指某个整数n等于某合数k（k≥4且非质数）的阶乘k!，如24=4!、720=6!；需预计算k=4,6,8,9,10,12,14,15,16,18,20对应的阶乘共11个值存入哈希表，查询时间复杂度O(1)。
什么是合数的阶乘，先搞清定义再写代码
“合数的阶乘”不是标准数学术语，实际要判断的是：某个整数 n 是否等于某个**合数 k 的阶乘**，即是否存在合数 k ≥ 4（最小合数是 4），使得 n == k!。注意：1、2、3 不是合数，所以 1!、2!、3!（即 1、2、6）即使结果是整数，也不算“合数的阶乘”。只有 4! = 24、6! = 720、8! = 40320 等才可能符合条件（但注意：5 是质数，5! 不算；9 是合数，9! 算）。
直接预计算比实时分解更可靠
阶乘增长极快，12! 就已超 4.7 亿，20! 超 2e18 —— 对于 int64_t 范围内的输入，真正需要检查的合数 k 只有：4, 6, 8, 9, 10, 12, 14, 15, 16, 18, 20, 21, 22, 24, 25, ... 但其实到 25! 已远超 uint64_t 上限（约 1.8e19）。实测：21! ≈ 5.1e19 > UINT64_MAX（1.8e19），所以安全上限是 k = 20，而其中合数只有：4, 6, 8, 9, 10, 12, 14, 15, 16, 18, 20（共 11 个）。预计算这 11 个值存入 std::unordered_set<uint64_t></uint64_t>，查询是 O(1)，且避免了浮点误差、大数分解、试除法误判等坑。
常见错误现象：
- 用 log(n)/log(k) 反推 k → 浮点精度丢失，log(24)/log(4) 可能不精确等于 2
- 对 n 做质因数分解再匹配阶乘结构 → 实现复杂、边界多（比如 n=1 或 n=0）、易漏判 9! = 362880 这类含重复小因子的数
- 从 k=4 开始循环算 k! 直到 ≥ n → 没问题，但不如查表快，且需小心溢出（k! 中间结果超限）
static const std::unordered_set<uint64_t> composite_factorials = {
24, // 4!
720, // 6!
40320, // 8!
362880, // 9!
3628800,// 10!
479001600, // 12!
87178291200, // 14!
1307674368000, // 15!
20922789888000, // 16!
6402373705728000, // 18!
2432902008176640000ULL // 20!
};输入边界和类型选择很关键
用户传入的 n 类型决定你能支持多大范围：
- 若用
int或long（常为 32 位），最大只到 ~2e9，那只需检查到12! = 479001600，13!就溢出了 - 若用
uint64_t，可覆盖到20!，但21!必须截断或报错 -
n == 0或n == 1：都不是合数阶乘（0!和1!对应的是 0 和 1，但 0、1 都不是合数；且题目隐含k是正整数合数） - 负数输入：直接返回
false，阶乘定义域是非负整数
别用 double 存 n —— 17! ≈ 3.56e14，double 在 > 2^53 后无法精确表示整数，查表会失败。
立即学习“C++免费学习笔记（深入）”；
查表实现要处理溢出和未定义行为
完整函数示例（C++17）：
bool is_composite_factorial(uint64_t n) {
static const std::unordered_set<uint64_t> cf = {
24, 720, 40320, 362880, 3628800,
479001600, 87178291200, 1307674368000,
20922789888000, 6402373705728000,
2432902008176640000ULL
};
return cf.find(n) != cf.end();
}容易踩的坑：
- 没加
ULL后缀导致字面量被编译器当int处理，2432902008176640000在 32 位系统直接溢出成负数或 0 - 用
std::set而非std::unordered_set→ 查询 O(log n) 而非 O(1)，没必要 - 忘记
static修饰局部静态变量 → 每次调用都重建哈希表，性能灾难 - 把
4!、6!算错（比如误以为5!合法）→ 本质是没严格按“k 是合数”筛选
真正难的不是算法，而是确认题意里“合数”是否包含 1（不包含）、是否允许 k=0（不允许）、n 的上界有没有说明——这些模糊点不厘清，代码再漂亮也判错。
