logrotate 同时配了 size 和 daily，到底是「谁先到谁轮转」还是「size 完全压过 daily」？故障窗口日志被提前轮走，你们怎么保？

背景 我们一台 RHEL 9 节点的支付网关日志（RHEL 9.2，logrotate 3.21.0，应用 Java 直写文件，非 systemd-journald），logrotate 配置是这样的：

/var/log/paygw/paygw.log {
    size 200M
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 paygw paygw
    sharedscripts
    postrotate
        systemctl reload paygw
    endscript
}

注意：这里只有 size 200M，没有 daily。当初写配置的人（不是我）的口头解释是「size 到了就轮，size 没到就一天一轮」——我后来翻 man logrotate 发现 size 的语义写的是 "use the specified size to determine when to rotate, in preference to the time interval"，也就是 size 一旦配了，时间间隔（daily/weekly）就完全失效，不是「双条件先到先触发」的 OR 语义。

现象 上周一个凌晨事故（12:40–13:10 支付回调风暴，日志量 1.8GB）复盘时发现：paygw.log.2 的轮转时间戳是 12:52，正好卡在故障窗口中间——也就是说故障后半段的日志在 .3/.4 里，而 rotate 14 + compress 之后，.12 之后的早被压缩归档挪走了，我们最后只拼回了 12:40–12:52 这 12 分钟的关键日志，剩下 18 分钟是黑盒，只能靠链路追踪里残缺的 trace 拼。

更让我警惕的是另一台机器上同样的服务，配置里 size 200M 和 daily 同时存在。我按 man page 的理解应该是 size 单独生效（daily 被忽略），但同事坚持认为「白天流量小，daily 会兜底，size 没到也轮」。我们俩谁都没法用实测说服谁。

已尝试的排查与结果

1. 翻 logrotate 3.21.0 man page：size 明确写 "in preference to the time interval"，且 hourly/daily/weekly/monthly 段落说 "one of these may be specified"——文字上支持 size 压过时间；
2. 但 man page 没有说 size 和 daily 同时出现时的行为（是 size 独占？还是取更严格的那个？），源码里 logrotate.c 的判定逻辑我没逐行啃；
3. 试了一个笨办法：本地起个脚本按 1KB/s 追加写，size 1M + daily 同时配，logrotate --debug 跑了一天——debug 输出里 size 未到时仍然打印了 "log does not need rotating"，但到底是 daily 在兜底还是 size 在判定，debug 日志分不清，这个实验我没能做成决定性证据；
4. 也检索了站内：沈砚舟-106 的《logrotate 三个默认值踩坑》（copytruncate/sharedscripts/su）和一条 K8s 场景的 logrotate inode 变化导致 otel 漏采的提问都很有价值，但都聚焦在「轮转机制的副作用」，没有覆盖「轮转时机到底谁说了算」这个上游问题。

期望得到的答案形态

1. 语义定论：size 和 daily 同时存在时，logrotate（最好给出版本）的实际判定逻辑是什么？最好能贴出关键源码行或一次可复现的对照实验（比如 logrotate --debug -v 在 size 未达/已达两种状态下的输出对比）；
2. 事故窗口保全：如果 size 语义确实「先到先轮」，那高流量时段日志轮转不可控，你们线上是怎么保证「故障那 30 分钟一定留得住」的？具体手段是什么（独立的 crash 日志目录 + 单独配置？按天命名 + 只 compress 不 delete？采集链路侧做双写兜底？）；
3. 配置规范：如果各位团队有 logrotate 配置的 review 清单或推荐模板，尤其想看看 size vs daily/minsize 的取舍——我现在的直觉是 minsize 50M + daily 才是「双条件 AND」的正确姿势，但同样没有实测背书。

一个开放问题想留给社区：日志轮转策略到底是「存储预算问题」（size 优先）还是「取证时间问题」（时间优先）？这两种优先级的冲突，你们组织里是怎么仲裁的？