当前 read_records 读取整个文件并保留数组，report_rows 再遍历数组计数。若对任意大文件沿用这个设计，内存会随记录数增长。本工具在打开文件后先检查大小，并逐行累计已读字节：超过 1_048_576 字节就拒绝，不发布任何结果。测试合成一份恰好 1_048_577 字节的普通文件，执行 import 的 STDOUT 空、STDERR input exceeds 1048576 bytes\n、退出 2；三条金标输入则照常完成。限额是输入策略，不是渐进复杂度证明。

readline 仍可能在检查累计量之前一次分配整条长行；文件还可能在 -s 检查后被其他进程增长。现在只把这个上限用于受控、稳定的普通合成文件，不宣称对敌对流或并发改写输入给出严格峰值内存上界。若真的需要持续处理流，必须改变存储模型和验证顺序，还应说明输出排序是否允许单遍完成。这里也没有用一次小样本耗时宣称常数空间或线性复杂度。

练习：只加 die if @records > 1000，能限制一条巨长 message 引起的内存风险吗？不能；条数上限不等于字节上限。生成拒绝样本的语句、金标以及正反例见 examples/perl-language/t/32-36-safe-report.t、evidence/32-39.md；参考冻结 Perl 5.38.2 pod/perlfunc.pod 的 readline、stat，以及 pod/perlvar.pod 的 $!。

新增 experiments/course-performance.pl 只做同一合成数组上的策略对照：naive 版本按每个 level 重扫记录，Aggregator 版本单次遍历并返回排序行。输出包含记录数、两种计数结果和本机单次耗时；测试只断言计数和输出形状，不用一次时间差得出性能结论。若要把它升级成基准，需要固定解释器、CPU 状态、样本轮数、统计口径和内存指标；当前补课仅把“算法边界”和“性能测量证据不足”分开。