洛谷 P5709 这道题的编号里带着【深基2.习6】熟门熟路的人一看就知道它的定位——入门阶段的分支与取整练习。题面短得可怜三四个输入量、一句话场景很多人扫一眼就觉得自己会了结果第一次提交直接红一片。它真正训练的东西不是算法而是把一段口语化的生活描述准确翻译成数学表达的能力具体说就是两件事什么时候该向上取整以及边界值退化时结果该怎么兜底。这道题适合刚学完输入输出、if 判断和整除运算的人拿来练手也适合已经刷了几十道题但总在细节测试点上翻车的人回头复盘。下面我按自己当时踩坑的顺序把建模思路、整数运算的推导、多语言实现和排查经验完整讲一遍苹果和虫子这个场景看着简单里面的门道比题面本身多。1. 题目场景重建与数学模型拆解1.1 三个输入量各自描述了什么题目给的是三个整数习惯上记作 m、t、s。m 是初始的完整苹果数量这个量在整个过程中只减不增是个库存概念t 是吃掉一个完整苹果所需要耗费的分钟数注意它是耗时而不是速度单位是分钟每个这个区别后面会直接影响公式怎么写s 是从开始到现在已经流逝的时间单位同样是分钟。虫子或者说吃苹果的主角的行为规则是吃完一个立刻开始吃下一个意味着它不会中途停下来休息时间轴上是连续消耗的。把这三个量放到一根时间轴上就很好理解了从 0 时刻开始第一个苹果在第 t 分钟被吃完第二个苹果在第 2t 分钟被吃完以此类推第 k 个苹果在第 k×t 分钟被彻底吃掉。那么在 s 这个时刻问题就变成了有多少个苹果已经被彻底吃掉剩下多少个还是完整无缺的。注意完整无缺这四个字这就是这道题唯一的、也是最容易被忽略的限定条件。正在被啃、啃了一半的那一个苹果不算完整苹果必须从答案里排除掉。1.2 为什么必须是向上取整而不是整除这是整道题最核心的一步也是绝大多数人第一次做会错的地方。直觉上很多人会写成 s / t用整数除法直接算出吃掉的苹果数然后 m 减去它。这个写法在 s 恰好是 t 的整数倍时是对的但在其他情况下会少算一个。举个实际的例子m 5t 3s 4。按照题面第一个苹果在第 3 分钟吃完第 3 分钟之后立刻开始吃第二个到第 4 分钟的时候第二个苹果已经被啃了 1 分钟了。这时候你数一数完整的苹果还剩几个第一个吃没了第二个被咬过了不算完整所以答案应该是 3。但如果用 s / t 4 / 3 1算出吃掉 1 个答案给 4就错了。正确的做法是把吃掉的苹果数算成 ceil(s / t)也就是向上取整4 / 3 向上取整等于 2正好对应第一个吃完了第二个已经动了这个状态。用生活化的说法向上取整的含义是只要碰过的苹果就算损失。这跟生活里卖水果的逻辑是一样的一箱苹果里有一个被咬了一口整箱就不能按完好品卖了。理解了这一层公式就固定下来了被消耗掉的苹果数 eaten ceil(s / t)剩下的完整苹果数 m - eaten同时结果不能小于 0。1.3 整数世界里的向上取整怎么写浮点数写法是最容易想到的ceil((double)s / t)或者(s t - 1) / t。前者有精度隐患虽然这道题的数据范围小到不可能出问题但养成习惯的话能不动浮点就不动浮点。整数写法的推导过程值得说一下对于两个正整数 a 和 b向上取整的结果等于(a b - 1) / b这里的除法是整数除法也就是向下取整。为什么这个式子成立把 a 拆成b × q r其中 q 是商、r 是余数0 ≤ r b。如果 r 0说明整除(a b - 1) / b (b×q b - 1) / b q (b-1)/b整数除法里后一项为 0结果是 q刚好等于向上取整的 q。如果 r 0那么a b - 1 b×q r b - 1 ≥ b×q b除以 b 至少是 q 1同时a b - 1 b×q b b除以 b 最多 q 1所以结果恰好是 q 1。两种情况合起来刚好就是向上取整的定义。这个式子在实际写题里用得非常频繁凡是遇到需要多少个容器才能装下 N 个东西至少需要分几组这类问题都是同一套逻辑。把它记熟比每次临时想一遍要省事得多。1.4 结果下限为什么必须夹到 0m - eaten 这个减法在某些测试点上会算出负数。比如 m 1t 1s 100eaten 1001 - 100 -99。但现实中苹果数量不可能是负的题目的隐含语义是苹果早就吃完了只是时间还在往后走。所以最终答案要在 0 处截断。这里有两种常见的写法一种是用条件判断一种是调用语言内置的求最大值函数。C 里可以用max(0, m - eaten)Python 里是max(0, m - eaten)Java 里是Math.max(0, m - eaten)。两种写法在功能上等价性能上也没有可观测的差异选哪个纯看个人习惯。我个人的偏好是条件判断因为它在任何语言里都一样不用担心头文件或者命名空间的问题而且在调试的时候打断点更直观。需要提醒的是夹到 0这个操作不能省。有些人心想我数据范围估过了不可能超结果就漏了这个判断。题目给的 m 上限只有 100而 s 的上限能到几千只要 t 足够小eaten 轻易就能超过 m这个测试点几乎是必然存在的。凡是有减法的地方先想清楚结果会不会变成负数这个反射要尽早建立起来。2. 核心细节与实现层面的坑点2.1 t 等于 0 这个绕不开的边界题面给 t 的取值范围下限是 0这个 0 让整道题的讨论区热闹了很多年。数学上说t 0 意味着吃掉一个苹果需要 0 分钟那 s 分钟内就能吃掉无穷多个苹果最后剩 0 个但从工程实现上说t 0 会让所有除法运算直接崩溃程序抛异常或者被平台判成运行时错误。比较务实的处理方式是在计算之前先特判如果 t 等于 0直接输出 0 并结束程序。理由是这样理解——耗时 0 意味着瞬时完成s 分钟里足够把全部的苹果消耗干净。这个判断放在读入之后、任何除法之前能彻底避免除零崩溃。如果你所在的评测数据对这一点有不同理解提交一次看看结果如果答案错误把它改成输出 m 再交一次两分钟就能验证清楚纠结理论不值得。还有一种更保守的写法是把判断写成if (t 0 || s 0)一起处理s 0 时时间还没开始走肯定剩 m 个。这种写法覆盖面更广缺点是逻辑上把两个不同性质的情况揉在了一起阅读时容易让人迷惑。我倾向于分开写代码清晰度比省几行更重要。2.2 数据类型是否需要 long long数据范围估算这件事做多了会形成条件反射。m 最大 100t 最大 100s 最大 10000那么s t - 1的最大值是 10099距离 32 位有符号整数约 21 亿的上限差了五个数量级用 int 完全安全。中间变量 eaten 最大也就 10000 出头减法结果最小是 -10000 左右同样不会溢出。那什么情况下需要考虑 long long如果题目把 s 的上限抬到 10^18s t - 1就有溢出风险了因为 10^18 99 还在 long long 范围内但如果是两个 10^18 级别的数相加就会溢出。判断标准很简单把每个变量的上界写出来看看参与加法或者乘法的两个数加起来会不会超过当前类型的上限。这个过程花不了一分钟但能省掉很多莫名其妙的 WA。顺便提一句向上取整的写法(a b - 1) / b本身自带一次加法在数据范围接近类型上限的时候要格外小心这是很多人没意识到的隐藏风险点。稳妥的做法是先把 a 和 b 都提升到更宽的类型或者改成a / b (a % b ! 0)这种形式虽然多一次取模运算但永不溢出。2.3 输入解析的容错性题目输入是一行三个整数用空格分隔。C 的cin 和 Java 的 Scanner、Python 的input().split()都能自动跳过任意数量的空白字符空格、制表符、换行所以不需要担心题目是不是真的只用单个空格分隔。这一点在早期的竞赛题里偶尔会成为坑老题目有时候用多个空格或者换行来分隔数据用 scanf 指定格式字符串容易读错。输出方面一个整数加一个换行就结束了。有些初学者会好心地在答案后面加一句提示文字比如cout left apples endl;这在本地看着挺友好提交上去直接判格式错误。评测系统的比对是逐字符的多一个字符都不行这个规矩要早一点刻进肌肉记忆里。2.4 关于完整苹果的语义再确认一遍在动手写代码之前把题目的关键词抠一遍是值得的。这道题里出现完整的苹果这个说法意味着被咬过的那个必须排除。如果是还剩多少个苹果不管完整与否那答案就是 m 减去已经彻底吃完的个数也就是m - s / t公式完全不同。这提醒我们一件事很多入门题的错误不是因为算法难而是因为读题时漏掉了一个形容词。我自己的习惯是读题时把所有的限定词圈出来数量词、状态词、时间点一个都不放过。这道题里完整立刻已经过去这三个词分别对应了判定标准、无间隔假设和时间区间缺一个都会导致建模偏差。3. 多语言实操与逐步骤验证3.1 C 版本从零到通过C 是这个平台上的主流选择写法也最紧凑。核心逻辑只有六行左右我把它拆开讲。#include iostream #include algorithm using namespace std; int main() { int m, t, s; cin m t s; // 边界吃一个苹果耗时为 0视为瞬时耗尽 if (t 0) { cout 0 endl; return 0; } // 向上取整算出已被消耗的苹果数 int eaten (s t - 1) / t; // 结果不能为负 int left m - eaten; if (left 0) left 0; cout left endl; return 0; }第一行读入三个整数cf 的输入流会自动处理空白。第三步的特判必须放在除法之前顺序错了就会触发除零。第四行是核心公式注意这里的除法必须是整数除法所以两个操作数都声明为 int如果你不小心写成(s t - 1) / (double)t结果会变成浮点后面的赋值会截断虽然本题数值小不至于出错但风格上不推荐。第五行的截断用 if 而不是max()纯粹是个人偏好用max(0, m - eaten)也一样能过需要包含 algorithm 头文件。整段代码没有任何循环时间复杂度 O(1)空间 O(1)在评测机上跑出来通常是 0 毫秒。3.2 Python 版本的简洁与陷阱Python 写起来更短但有两个地方需要注意。m, t, s map(int, input().split()) if t 0: print(0) else: eaten (s t - 1) // t print(max(0, m - eaten))第一个注意点是整除符号必须用//而不是/。Python 3 里的/是真除法5 / 2 得到 2.5用在需要整数的场景会出问题。虽然这里用 max 和减法看起来也能算出正确答案但一旦数值变大就会引入浮点精度问题超过 2 的 53 次方之后整数就存不精确了。养成用//的习惯。第二个注意点是input().split()得到的是字符串列表必须经过 map(int, ...) 转换才能参与算术运算。如果直接写m, t, s input().split()后面做减法的时候会报类型错误。这个坑新手几乎必踩一次。另外 Python 里也有math.ceil写法是math.ceil(s / t)但同样要引入 math 模块并且经过浮点转换能用整数运算解决的事情就不要绕道浮点。3.3 Java 版本与输入输出选择Java 的代码量会多一些主要是类声明和输入对象的创建。import java.util.Scanner; public class Main { public static void main(String[] args) { Scanner sc new Scanner(System.in); int m sc.nextInt(); int t sc.nextInt(); int s sc.nextInt(); if (t 0) { System.out.println(0); return; } int eaten (s t - 1) / t; int left m - eaten; if (left 0) left 0; System.out.println(left); } }类名必须叫 Main这是评测环境的硬性要求叫别的名字会直接编译失败或者找不到入口。Scanner 在这个数据规模下完全够用不需要换成 BufferedReader 或者自定义快读。有些刷题模板会一上来就贴一套快读类对于这道题来说是过度设计代码多了一倍可读性反而下降。我的建议是数据量在十万级别以下时Scanner 的便利性远大于它的性能损失。如果确实想用 BufferedReader读取一行的写法是String[] parts br.readLine().split( );然后逐个Integer.parseInt步骤更多容易在空行或者多余空白上出错。入门阶段没必要给自己加这些负担。3.4 手工验算与测试用例设计写完代码不要急着提交先在草稿纸上算几组数据对一下。这一步花的时间短但能捞回不少低级错误。我整理了一组覆盖各种情况的用例。输入 m t s推导过程期望输出覆盖场景5 3 4ceil(4/3)25-233基本场景非整除5 3 3ceil(3/3)15-144恰好整除无半个1 1 1ceil(1/1)11-100刚好消耗完10 1 100100 个被吃10-100 为负0结果截断到 07 5 11ceil(11/5)37-344多个苹果余数较大9 4 8ceil(8/4)29-277第二次整除100 0 5特殊分支0耗时为零的边界表格里的第一组和第五组最能说明问题。第一组 s 4 而 t 3如果错误地用了整除答案是 4正确是 3差异一眼能看出来。第五组 s 11、t 511 除以 5 整数部分是 2向上取整是 3差值同样明显。把这两组先跑通基本就能确认公式写对了。第七组是专门给 t 0 准备的跑一下看看程序有没有崩。如果本地直接抛出除零异常说明特判位置不对或者遗漏了。4. 提交后各种异常现象与排查实录4.1 判题结果的含义对照第一次提交之后评测机给出的英文缩写含义要先搞清楚否则会浪费很多时间。答案错误表示输出和标准答案不一致最常见的原因是公式错误、漏掉了向上取整或者没有做下限截断运行时错误表示程序中途崩了这道题里几乎百分之百是除零也就是 t 0 的分支没处理编译错误表示语法问题比较常见的是忘记写命名空间、括号不配对、变量名拼错时间超限在这道题上基本不会出现因为没有任何循环如果有的话说明代码结构写歪了。还有一种是格式错误输出中多了或者少了字符换行符也算。有些人习惯在最后多输出一个空行多数评测系统能容忍但这不是好习惯早点改掉。把这几种结果的成因对应起来排查效率会高很多。看到运行时错误就不要去检查公式了直接去翻除法那几行。4.2 本地通过提交不通过的典型原因最常见的一类情况是本地测了几组手算数据都过了提交却红了一半。原因通常是漏测了某个极端数据。这道题最容易漏的就是 t 0 和结果截断这两种。手工测的时候人总会下意识选正常的数据比如 t 取 2、3、5 这样的小整数很难想起来去测 t 等于 0。我的应对办法是写代码之前先把极端值列出来每个输入量的最小值、最大值、以及那些会让公式退化的特殊值。这道题的清单就是 t 0、s 很大导致 eaten 超过 m、m 1 这种情况。设计用例的时候照着清单一条条来比凭感觉测要靠谱。另一类情况是本地环境和你提交时用的编译器版本不同导致某些行为有差异。这在入门题里很少见但如果你用了某些新标准的语法特性确实可能翻车。稳妥起见入门阶段的代码就用最朴素的写法不追求语言特性。4.3 提交页面自身出问题时的处理偶尔会遇到提交之后页面跳出一堆看不懂的提示或者点了提交按钮半天没反应成绩列表不更新。这种情况多数是页面资源没有完整加载或者本地网络到平台服务器之间的链路抖动跟你的代码没什么关系。处理方式很朴素刷新一次页面重试或者等几分钟再交换个时间段提交通常就好了。需要区分的是页面报错和你的代码报错。前者不会出现在提交记录里后者会在记录列表里留下一条带颜色标记的结果。如果你在记录里看到了自己的提交那问题一定在代码不在页面。分清楚这个界限能省掉很多无谓的焦虑。顺便说一下浏览器缓存有时候会导致提交按钮点击无效清理缓存或者用无痕窗口打开能解决。这类问题在任何一个在线判题平台上都会偶尔发生属于平台的常态而不是异常。4.4 常见问题速查表把上面提到的内容整理成一张表遇到问题可以快速对照。现象大概率原因处理方式答案错误差 1用了整除而非向上取整改成 (s t - 1) / t答案错误差了很大结果没截断为 0加 max(0, ...) 或 if 判断运行时错误t 0 触发除零除法前特判 t 0编译错误找不到标识符缺少头文件或命名空间检查 include 和 using编译错误找不到主类Java 类名不是 Main把类名改成 Main提交后页面报错无记录前端资源或网络问题刷新重试换个时间段表格里第一行和第二行是最频发的把这两条刻在脑子里这道题基本就稳了。4.5 从这道题延伸出的几个刷题习惯做完这道题之后有几个习惯值得顺手建立起来。第一个是先写边界清单再写代码把每个输入量的极端情况和公式的退化条件列出来写代码的时候逐条对着处理比写完再补要高效。第二个是任何除法之前问一句除数会不会是零这个反射能挡掉大量的运行时错误在后续更复杂的题目里同样有用。第三个习惯是把向上取整的公式记成肌肉记忆不要每次现推。它的变体非常多凡是涉及至少需要多少个的问题都能用上比如容器装物、按页分栏、按批次切分。第四个习惯是本地测试一定要覆盖答案被截断这一种情况因为人脑天然倾向于相信结果总是正数而程序不会。还有一个跟题目本身无关但很实用的体会入门阶段的题目代码越短越好不要把后面学的模板提前搬过来。这道题用十行就能写完非要套一个快读类加一个宏定义集合除了增加出错面积之外没有任何收益。等到数据规模真的需要优化时再优化这个顺序不能颠倒。我个人的经验是像 P5709 这样的题做一遍能过不算什么能在不看答案的情况下把 t 0 和结果截断这两个点想起来才算真的把这类型题吃透了。后面再遇到同类场景脑子里会直接跳出向上取整加下限截断这个组合那时候写题速度会明显快一截。