第478场周赛的Q1题号3759题目叫“统计合格元素的数目”放在第一题的位置上属于那种看起来平平无奇、写起来也不该超过五分钟的保分题。但奇怪的是每场周赛的Q1其实翻车率并不低尤其在这种以“统计”为名义的题目里出题人总会在边界条件上埋点东西。这篇我就拿这道题当引子把周赛Q1的通用解法、代码实现和实战坑点一次讲透无论你是刚开始打周赛的新手还是想稳定手速的老选手都可以直接参考。1. 从题名看考点为什么要刷这道Q11.1 “统计合格元素”不是送分那么简单“统计合格元素的数目”这个表述信息量其实很低低到几乎任何周赛Q1都可以叫这个名字。但也正因为如此它才很考验一个选手读题的能力题目到底在统计什么合格条件是什么哪些位置参与统计以我平时刷题的经验来看这类题最常出现的合格条件无非是下面几种元素的值大于等于某个阈值元素的值落在某个区间内元素满足和首尾元素的大小关系。放到3759这题里从标题里的“合格”加上周赛Q1的难度定位来推断大概率是给你一个数组然后让你遍历除首尾之外的元素检查它是否同时满足和数组第一个元素、最后一个元素的大小关系满足就计入答案。为了后面方便讲解我给一个具体化的推断版本给定数组nums统计满足nums[i] nums[0]且nums[i] nums[n - 1]的下标i的个数其中i从 1 到n - 2。如果你的题面里写的是别的条件比如大于等于改成了小于等于或者判断对象换成了左边所有元素的最大值替换判断逻辑即可整体框架完全通用。这类题目看起来就是一次遍历但真正拉开差距的地方在于你有没有在一开始就把“首尾到底参不参与判断”想清楚。很多选手不是输在不会写循环而是输在边界处理上这也是我在文章后面会重点展开的部分。1.2 周赛Q1的真实定位打周赛的人都有一个共识Q1不是拿来秀操作的是拿来稳定拿分的。一场周赛的四道题里Q1和Q2基本决定了你能不能保住名次的下限Q3、Q4才决定上限。所以对待Q1的正确态度不是追求什么优雅算法而是求快、求稳、求一次通过。从近几十场周赛的趋势看Q1已经不太满足于纯“数组求和”这类闭着眼写的题目了它开始往“读懂题意再写循环”这个方向靠。比如让统计满足某些条件的元素或者让找满足某种性质的子数组数量。题目难度依然是简单但文字游戏和边界陷阱变多了。这种变化其实和整体题目风格有关。我看过第430场周赛的题目那时候Q1就已经开始要求选手在几分钟内迅速完成从文字到逻辑的转换不再是无脑模拟。到了第478场这套逻辑更成熟了给一个稍有包装的统计题考察的就是你的代码基本功外加细心程度。所以说刷这道题不是单纯为了记住某个数组如何遍历而是通过它训练一套“拿到Q1题后如何在最短时间内建模并写对”的肌肉记忆。2. 核心思路与算法设计线性扫描就够2.1 把“合格”翻译成判断表达式从算法层面讲这种题没有任何弯弯绕绕遍历、判断、计数三步走。但在动手之前有一个关键动作先把题面里的“合格”翻译成一个明确的布尔表达式。什么叫翻译就是把自然语言转换成可以用来写if的逻辑。比如题面说“元素值大于等于首元素和末元素”那么翻译结果就是nums[i] nums[0] nums[i] nums[n - 1]如果题面说“元素值不超过首元素的1.5倍”那就写成nums[i] nums[0] * 1.5。这一步看起来简单但正是区分能不能一次写对的分水岭。因为很多人在读题时下意识认为自己懂了结果写出来的判断条件差了一个等号或者少了一个边界下标提交之后就是一个罚时。尤其周赛环境里WA一次意味着排名跌一截非常伤。我可以给一个随手写出的例子。假设题面要求是“统计数组中间那些不大于首元素也不小于末元素的元素个数”那么代码骨架就是if (min_val nums[i] nums[i] max_val) { ans 1; }难点从来不在写if而在于你用的min_val和max_val到底取的是哪两个值。这决定了整个答案的方向也是下一节我要聊的核心。2.2 排除首尾元素的关键性为什么几乎所有这类题目都要把首尾元素单独拎出来因为如果首尾元素也参与计数那么nums[0]自己和自己比较必然成立nums[n - 1]同样如此结果每道题至少会多出两个计数。出题人让你统计的是“中间元素里满足条件的个数”目的就是把边界值排除在考察范围之外。这个“排除首尾”的操作在实现上分两种一种是用for i in range(1, n - 1)来限定遍历区间另一种是在循环里用if i ! 0 i ! n - 1跳过。第一种显然更干净也是我推荐的写法。但这里藏了一个新手最容易忽略的点如果数组长度很短呢比如n 1那么区间[1, n - 1)是空区间循环本身就不会执行答案是 0没问题。如果n 2区间[1, 1)同样是空的答案也是 0。但如果有人在循环外先取了nums[0]和nums[n - 1]在n 1的时候nums[0]和nums[n - 1]是同一个元素这在逻辑上没问题可一旦你习惯性地访问nums[n - 1]只要nums非空就安全。真正危险的是有人把数据范围看错以为数组至少有 3 个元素结果被边界样例卡掉。所以我打周赛时有个习惯见到“统计中间元素”这类字眼直接在草稿纸上写下range(1, n - 1)然后单独问自己一句如果数组只有 0 个或者 1 个元素代码能不能跑通2.3 边界与等号的取舍逻辑另一个高频翻车点是等号。题面到底写的是“大于”还是“大于等于”“小于”还是“不超过”别小看一个等号的区别它直接决定答案是否包含等于边界值的元素。从周赛题目的一贯风格来看这里要特别留意题面的用词。如果题目用了at least或者“不低于”那就要带等号如果用了“严格大于”那就不带。中英文表述里这种细节很容易在快速读题的时候滑过去。我自己的做法是读完题后立刻在代码旁边写一个极小的注释比如nums[i] nums[0]把判断条件固化成文字以免写着写着把逻辑改了。这个方法看起来很笨但在 20 分钟三连提交的高压场景下确实能救回不少失分。等号的错误通常不会被样例发现因为题目给的示例往往就那几个覆盖不到所有边界。我能给出的最有效建议是假设你自己就是出题人想一想你会用什么数据来卡选手。通常就是全相等数组、只有两个元素、最大值出现在首尾这几种。把这几个用例先在脑子里跑一遍再去提交比反复罚时要划算得多。3. 代码实现与实操要点3.1 Python版本示例先给出我最常用的Python解法。这份代码可以直接作为周赛提交模板class Solution: def countElements(self, nums: List[int]) - int: n len(nums) if n 3: return 0 left nums[0] right nums[-1] ans 0 for i in range(1, n - 1): if nums[i] left and nums[i] right: ans 1 return ans这里我直接把n 3的情况提前返回了。有些人会觉得这个判断多余因为即使n是 0、1、2循环也不会执行最后返回 0 是一样的效果。但加上这行语义更明确还能避免你在后面的代码里想当然地访问nums[-1]时会出现的别扭感觉。Python里还有一个更简洁的写法用sum加生成器return sum( 1 for i in range(1, len(nums) - 1) if nums[i] nums[0] and nums[i] nums[-1] )两种写法复杂度一样都是 O(n) 时间、O(1) 空间。哪种更合适取决于你是否习惯函数式写法反正提交都稳。3.2 Java与C版本对应写法如果是Java核心代码框架如下class Solution { public int countElements(int[] nums) { int n nums.length; int left nums[0]; int right nums[n - 1]; int ans 0; for (int i 1; i n - 1; i) { if (nums[i] left nums[i] right) { ans; } } return ans; } }C版本也基本一致class Solution { public: int countElements(vectorint nums) { int n nums.size(); int left nums[0], right nums[n - 1]; int ans 0; for (int i 1; i n - 1; i) { if (nums[i] left nums[i] right) { ans; } } return ans; } };如果你用的是C有一点值得注意nums.size()返回的是无符号整数如果你比较i nums.size() - 1当nums为空时nums.size() - 1会变成一个非常大的正数导致循环进入后越界访问。所以我在C版本里先把n取出来转成int再用n - 1。这个坑在很多看起来无害的代码里出现过顺手就能规避。3.3 周赛现场的编码顺序有些新手打周赛时一看到题目就急着动手敲代码这是效率最低的节奏。比较合理的顺序是先在草稿纸上读一遍题把输入、输出、条件各圈一遍。确定合格条件的具体表达式。想清楚边界情况尤其是数组长度和首尾元素。写代码提交。整个过程控制在三到四分钟以内。因为Q1基本不需要复杂的推导多想一分钟都是浪费。但这里说的“多想”是指想清楚边界不是让你发呆大家要分清二者。在上面的Python例子里我选择先把nums[0]和nums[-1]存成变量而不是在循环里反复访问。这不是什么性能优化纯粹是为了让代码读起来更清楚。等你调试的时候也能直接在本地查看left和right的值减少一次心智负担。4. 实战排查这题最容易翻车的几个地方4.1 数组长度只有1和2这是最典型的隐蔽用例。题目大概率不会在示例里给出nums [1]或nums [1, 2]因为这样的输出是 0看起来太无聊。但评测数据里一定有而且就是为了卡那些没有考虑边界就直接从下标 1 循环到n - 1的选手。我就亲眼见过有人写这样的循环for i in range(1, n - 1): left nums[i - 1] right nums[i 1]当n 2时循环区间是[1, 1)不会进入所以没有报错。但当n 0时如果你先访问了nums[0]就直接越界。LeetCode 的题面通常会给出nums.length 1但你不能指望这种保证代码里要稳一手。我的习惯是一律在开头处理n 3的情况把答案直接置为 0。理由很简单逻辑上很多题设默认数组至少有三段结构左边界、中间段、右边界。没有三段就不存在中间段统计结果必然是 0。4.2 首尾元素相等的特殊情况还有一种常见讨论如果nums[0]等于nums[n - 1]判断条件会怎样答案是完全不受影响。因为条件里比较的对象是固定的两个数它们相等时就变成一个统一的阈值。比如nums [2, 1, 2, 4, 2]左边界和右边界都是 2那么统计的就是中间部分大于等于 2 的元素也就是索引 1 的 1 不满足索引 2 的 2 满足索引 3 的 4 满足结果是 2。如果你在实现时不小心把判断写成了nums[i] nums[0] || nums[i] nums[n - 1]用or代替and那么只要大于其中一个边界就算合格在首尾汇聚的用例上不会出错但在nums[0]很大、nums[n-1]很小的用例上就会多计数。这属于典型的条件翻译错误。我记得自己有一次就是在这种题上把and写成了orWA 了一次才发现。所以现在凡是遇到多重条件我都会默念三遍全部满足还是任一满足。4.3 看错题意等于零分“统计合格元素的数目”这个题名太有迷惑性它完全没说“合格”的定义是什么。这就导致一个问题有些选手会在心里自动补一个“符合常识”的定义然后兴冲冲地提交。比如有人会觉得合格元素应该是“比左边所有元素大比右边所有元素小”这完全是从脑筋急转弯式的题目里带出来的惯性。一旦题面根本不是这个意思结果就是零分。所以读题时不要急尤其是Q1这种很短很简练的题它可能就用一句话说完条件你要做的就是抓住那句话里的每一个单词。我给自己的要求是至少把题面读两遍。第一遍抓输入输出格式第二遍抓判断条件。两遍之间隔几十秒让大脑从“我要赶快写代码”的兴奋中冷静下来。很多时候第二遍就会发现自己第一遍漏掉的限定词。4.4 从第430场到478场Q1的难度变化我特别关注了一下最近几十场周赛的Q1走向。第430场左右的时候Q1基本还是纯模拟题目会直接把条件写在脸上提示也很充足。但越往后尤其是到了470多场Q1开始喜欢做“概念包装”给题目起一个略显宽泛的名字然后在描述里给出一堆自定义规则。这其实是一个信号动态规划、双指针这些硬核考点在Q4可能变化不大但Q1在考核选手“快速理解规则”的能力上明显加码了。3759这题就是典型的例子“合格元素”这四个字没有给出任何提示你必须自己去描述里找条件。这种趋势意味着周赛的难度感受不完全来自算法本身还来自题目表述的复杂度。所以我在刷题时不再只练“写代码”也开始练“把文字快速转换成代码框架”的能力。多参加周赛、多复盘读题错误比盲目刷大量同类题更管用。5. 个人体会与实用扩展这道题本身不难属于标准的“一遍过”题。但越是这样我越建议你不要直接跳过。我常对身边准备校招的朋友说周赛Q1是性价比最高的练习素材它的算法背景不深却包含了完整的问题建模过程。你可以在Q1上测试自己从读懂题意到写代码的时间以及在不同边界用例上的敏感度。把这些练稳了比死磕一两道难题更能提升周赛成绩。另外一个可以扩展的点是这种“统计满足条件的元素”的套路可以自然延伸出很多变体。比如把条件改成“大于左边最大值”那就要用前缀最大数组预处理再比如把条件改成“同时大于左右两侧所有元素”那就是另一道稍难一点的题。所以不要小看这个Q1模板它是后面很多中等题的地基。如果让我给一个具体的练习建议那就是把近十场周赛的Q1拿出来限定8分钟内完成从读题到通过做不到就反复做。这比每天刷两三百道随机题要有效率得多。打周赛不只是比知识储备更多的是比在有限时间内稳定输出简单题的能力而这道第478场的Q1正是练这种能力最好的素材。
