if嵌套判断1到100区间：从输入校验到代码优化的完整实践

这个标题看起来朴实无华，但它几乎是所有编程初学者都会撞上的一面墙：给定一个1到100之间的整数，用if嵌套结构判断它落在哪个区间。很多教程会把这道题草草带过，直接甩一段代码让你抄，但真正让人卡住的从来不是语法，而是“这个分支为什么要这么套”“边界值到底归谁”“用户输入的不是数字怎么办”。这篇文章我会从需求拆解一步步讲到调试排错，最后再聊几句嵌套结构的工程尺度问题，希望你看完能真正把它消化成自己的东西。

1. 这个练习到底在练什么：需求拆解与设计思路

1.1 一句话看懂需求

先把这个需求翻译成人话：程序先让用户输入一个数字，然后判断这个数字在1到100之间属于哪个部分。如果输入的数字不在1到100范围内，要给出提示；如果在范围内，再进一步细分出它是“小数字”“中等数字”还是“大数字”这类区间结论。

注意这里的关键词是“用户输入”。这意味着程序不是预先写死一个数去比较，而是要通过input()这类函数从键盘读取，并且读进来的东西首先要解决“能不能转成数字”的问题。很多初学者在这里就翻车了：直接拿字符串和整数做比较，Python里会报TypeError，Java里会编译不过，C语言里更是直接拿ASCII码在比。这一点我会在后面的校验环节专门展开。

另一个隐含需求是“if嵌套”。为什么题目特意点名嵌套而不是用一串if...else if...？因为嵌套结构天然对应“先做一次粗筛选，再做细分类”的层次逻辑，它能更好地训练你思考判断的先后顺序。

1.2 为什么用嵌套而不是多个独立if

如果只是判断1到100的区间，你完全可以用三个独立的if分别判断，写成：

if num >= 1 and num <= 33: print("小") if num >= 34 and num <= 66: print("中") if num >= 67 and num <= 100: print("大")

这样也能跑，但它有三个问题。第一，每次都要重复写两遍范围条件，代码冗余；第二，每个if都会做一次完整判断，效率上虽然差别不大，但这种写法一旦遇到更复杂的业务（比如先判断用户是否有权限，再判断操作类型，再判断金额是否足够），就会彻底失控；第三，三个独立if之间没有层次感，别人读代码时没法一眼看出什么条件是前提。

嵌套的写法类似于先过一道安检门，再分流到不同的候车区：

if 1 <= num <= 100: if num <= 33: print("小") elif num <= 66: print("中") else: print("大") else: print("超出范围")

外层if先干一件事：把不在1到100的数直接挡在门外。只有通过了这道门槛，内层才开始细分。这种结构的优势是逻辑顺序清晰，维护的时候你只需要关心当前层这一件事。内层判断里连num >= 1都不用再写，因为能进入这个分支，就说明前面已经确认过了——这就是嵌套节省重复条件的核心价值。

1.3 一个接地气的场景：成绩定级

光判断“大中小”有点抽象，工作中更常见的场景是成绩定级：输入一个0到100的分数，输出优秀、良好、及格、不及格。这个场景和标题需求本质上完全一样，只是把区间换成了评级标准。

我当年带新人练习时，一直用这个案例替代干巴巴的“大中小”教学，因为它的反馈更直观。输入88，打印“成绩优秀”，输入45，打印“不及格”，学生能立刻看到自己和现实世界的连接。而且成绩定级天然包含多层嵌套需求：外面先判断分数是否有效（0到100），里面再按90、75、60的界限拆分，完全契合本项目的练习目标。

2. 从零手写：第一版能跑的if嵌套代码

2.1 先写外层判断：锁定1-100区间

不管内层怎么分，第一层永远是边界校验。这个顺序千万别反。很多新手一上来就写if num < 50，然后发现负数也进了“小”这个分支，这就是因为最外层没有先做范围锁定。

外层判断在Python里可以写成区间比较链：

if 1 <= num <= 100: # 在这里面做区间细分 ... else: print("输入不在1到100之间")

Java和C系语言不支持连续比较，你得写成if (num >= 1 && num <= 100)。这一点跨语言时要格外小心，我见过不止一个从Python转到Java的人在这语法上被编译器教育了半天。

外层锁定的意义实际上是“尽早返回”。用一个生活化的类比：快递分拣员不会先仔细看包裹上的楼层，然后才想起来地址不在配送范围。他是看一眼城市标签，不在本市就直接扔到退回筐里，后面的事完全不用管。代码也是一样的道理，把无效输入先滤掉，后面的分支才能安心地做减法。

2.2 内层细分区间：三个分支怎么排

假设我们把1到100分成三段：1到33为“小”，34到66为“中”，67到100为“大”。内层可以写成：

if 1 <= num <= 100: if num <= 33: print("小数字") elif num <= 66: print("中等数字") else: print("大数字")

这里有个非常容易踩的坑：很多人喜欢把第二个条件写成elif num >= 34 and num <= 66，第三个写成elif num >= 67 and num <= 100。这种写法结果没错，但实际上是画蛇添足。你想，程序执行到内层的elif时，已经知道了num > 33（因为第一个if不成立才走到这里），所以第二个条件只需要写num <= 66就足够了。同理，走到else时，已经自动满足num > 66，连条件都不用写。

这个“能用递减条件就不重复写完整区间”的习惯，是嵌套结构里最容易养成也最有价值的思维。它逼着你去想“程序执行到这里时，哪些事实已经是确定的了”，你一旦熟练运用这种推理，读代码的速度和理解深度都会上一个台阶。

2.3 这一版代码的坑：输入类型与重复取值

把上面的判断逻辑放进一个完整的可运行程序里：

num = int(input("请输入一个数字: ")) if 1 <= num <= 100: if num <= 33: level = "小数字" elif num <= 66: level = "中等数字" else: level = "大数字" print(f"{num} 属于{level}") else: print("输入不在1到100之间")

这段代码在用户规规矩矩输入一个整数时是完美的。但用户从来不会规规矩矩。你让别人输入数字，他可能输入abc，可能输入12.5，可能输入一个空行，甚至可能输入五十。int()函数遇到这些内容时，会直接抛出ValueError，程序瞬间崩溃。

这就是“用户输入”这个热搜词背后真正的痛点：你写的代码不能只处理理想的输入，还得把脏数据接住。严格来说，这个需求在真实项目中，外层判断应该先做类型校验，再做区间校验，最后才做嵌套判断。我把它放到第3节专门处理。

另外还有一个值得注意的细节：如果你只是打印区间结论，内层每个分支里重复写print也没问题。但如果你想在退出嵌套之后继续使用这个结论（比如做后续计算），最好用一个level变量把结果保存下来，而不是每个分支里直接打印。上面示例代码里就是这么做的，这种“先计算后输出”的结构习惯，后面扩展起来会省很多事。

3. 判边界不崩溃：输入校验与边界值处理的完整方案

3.1 非数字输入的拦截

在正式做范围判断前，必须先把输入内容从字符串转成数字。但转换本身就可能失败，所以需要try...except接住异常：

try: num = int(input("请输入一个1到100的数字: ")) except ValueError: print("输入无效，请输入一个整数") exit()

这样用户输入abc时，程序不会崩溃，而是友好地提醒一句并退出。如果你想要更严谨一点，不用exit()，而是用循环让用户重新输入，直到输入合法为止：

while True: raw = input("请输入一个1到100的数字: ") try: num = int(raw) break except ValueError: print("那不是整数，再试一次。")

这个while True加break的模式，在处理“用户反复输错”这个场景里几乎是标准答案。它把类型校验做成一个闭环，用户输错一次就再给一次机会，直到拿到一个干净的整数为止。这个循环本身不涉及嵌套判断，但它保证了后续的判断代码拿到的数据一定是安全的。

3.2 1和100这样的边界值归谁

边界值是最微妙的问题。按上面的写法，num == 1会进入“小数字”，num == 100会进入“大数字”，这没问题。但如果你把区间定义改成“1到33为小、34到66为中、67到99为大、100单独处理”，那么边界的归属就变得敏感了。

判断边界归属有三个原则：

第一，区间定义必须覆盖全部有效值，不能漏掉任何一个整数。比如你用1 <= num < 33、33 <= num < 66、66 <= num < 100、num == 100这样去切，也能做到不重不漏，但分支数量变多了，看着就累。

第二，每个分支的条件顺序一旦定下来，就不要随意调换。因为elif是按顺序匹配的，第一个匹配上的分支执行完后，后面的分支不会再检查。只要顺序固定，边界值就会有一个确定的去处。

第三，最好的习惯是把边界值在测试用例里明确列出来。比如测试1、33、34、66、67、100这几个数，确保每个值都落到预期的区间里。我见过很多人在线上代码里因为边界值归属问题产生bug，比如生日判断、年龄分级、费用阶梯计算，全是这一类问题。尽早养成列边界测试用例的习惯，能省无数事后排查的时间。

3.3 负数、小数、00、带空格输入怎么处理

你以为只要接住ValueError就万事大吉了，实际上的脏数据远比你想象的多样。

负数：int("-5")不会报错，它会被转成整数-5。所以类型转换通过并不代表范围正确，后续的1 <= num <= 100外层判断会把负数正确挡在外面。注意这里不要省略负数这个场景的测试，因为很多人只测了101这种超上限的，忘了测负的。

小数：int("12.5")在Python里会报错，但float("12.5")不会。如果业务上需要允许小数，可以在类型转换时用float()，然后把区间条件改成1.0 <= num <= 100.0。但标题明确说的是“数字”，没有强调整数，所以这里要看你自己的需求来定。作为练习，我建议先锁定整数输入，等基础逻辑跑通了，再扩展到小数场景。

00：用户输入00时，int("00")会得到0。这其实是一个会被外层判断正确拦截的边界值，因为0不在1到100范围内。问题在于，用户可能觉得自己输入了“00”就是“100以内的某个数”，但按照严格定义它确实是0。这一类情况不需要特殊处理，只要记住输出提示信息时把用户的原输入呈现出来，让他自己理解哪里出了问题就好。

带空格输入：用户可能在数字前后敲了空格，比如输入" 42 "。Python的int(" 42 ")会自动忽略首尾空白并正确转换，所以这个场景在Python里不需要额外处理。但如果你用的是某些比较严格的语言或框架，可能就得先strip()一下再转换。这个细节虽然小，但在处理真实用户输入时非常常见，值得留意。

把这些校验逻辑全部整合起来，一个相对完整的程序长这样：

while True: raw = input("请输入一个1到100的数字: ") try: num = int(raw) except ValueError: print("输入无效，请重新输入。") continue if num < 1 or num > 100: print("数字必须在1到100之间。") continue if num <= 33: level = "小数字" elif num <= 66: level = "中等数字" else: level = "大数字" print(f"{num} 属于{level}") break

这个版本把类型校验、范围校验、嵌套判断依次串联起来，用户可以反复输错直到正确，每一次失败的输入都有明确的提示。这才是真实场景下“用户输入”应该有的交互体验。

4. 糊涂账怎么查：调试方法和常见错误速查

4.1 三个最容易翻车的逻辑错误

第一批坑往往不在代码本身，而在对条件的理解上。

第一个错误是把elif写成了独立的if。这个错误的后果是：当num满足某个区间时，后续的if还会继续检查，一旦条件有重叠，同一个数可能被多次匹配，输出多行结果。比如你把内层三个分支都写成if，输入50时，第二个if会输出“中等数字”，但如果你第三个if误写了num >= 50，它又会输出“大数字”，结果就乱了。嵌套结构里能用elif串联的分支就坚决别用if。

第二个错误是大于号小于号写反。if num <= 33和if num >= 33完全是两回事，差之毫厘谬以千里。这个错误尤其容易在疲劳或复制粘贴时出现，而且它不会让程序报错，只会让结果悄悄变错，排查起来特别费劲。我的经验是：写完整段判断后，专门把所有比较运算符逐字读一遍，这比事后debug快得多。

第三个错误是忘记else分支。如果你只写了if num <= 33和elif num <= 66，但忘了最后的else，那么当num为80时，程序可能什么都没输出，静默地跳过了整个判断块。这种“什么都不输出”的bug比报错更让人摸不着头脑。所以你在设计嵌套结构时，每一层都要问自己：如果所有条件都不满足，程序应该做什么？哪怕只是打印一行日志，也比什么都不做强。

4.2 人肉走查和打印大法

程序出了错，第一步不是改代码，而是定位问题。对于这种几行的嵌套判断，最有效的调试工具是“人肉走查”：拿笔在纸上画出判断流程，挑几个有代表性的数字（比如1、33、34、66、67、100、101、-5）逐个走一遍。

拿num = 34举例：外层1 <= 34 <= 100成立，进入内层；第一个条件34 <= 33不成立，跳过；第二个条件34 <= 66成立，执行输出“中等数字”。逻辑正确。这就是一次完整的人肉走查。

如果逻辑复杂到人肉走查会绕晕，那就用打印大法：在关键分支里临时加print("debug: 进入外层")、print("debug: 进入内层小数字分支")之类的输出。程序跑起来后，你从打印信息里能直观地看到实际执行了哪条路径，就能立刻发现判断顺序的问题。这些都确认无误后，再删掉打印代码，保持输出干净。

4.3 常见问题排查表

我把平时带新人时最常遇到的情况整理成一个速查表，你照着逐个检查，能省下不少瞎猜的时间。

这里头的排查技巧就一条：先确认输入环节是否干净，再看判断条件。大部分嵌套逻辑写错的情况，通过人肉走查几个边界值都能快速定位，真正难难搞的反而是那些因为输入类型导致的隐性崩溃。

5. 嵌套不是越深越好：代码优化与工程思维

5.1 用数学计算替代部分嵌套

分段判断这类问题，往往存在数学上更优雅的解法。比如1到100分成三段均匀区间，你可以直接用除法和取整来算区间编号：

level = (num - 1) // 33

当num为1到33时，(num - 1) // 33为0；34到66时为1；67到100时为2。这样就可以用一个字典做映射：

level_names = {0: "小数字", 1: "中等数字", 2: "大数字"} print(level_names[(num - 1) // 33])

这种做法的优点非常明显：没有一堆分支嵌套，代码短了一大截，区间数量改变时只需要调整除数。缺点也比较明显：公式的含义不如if清晰，等分区间不均匀时数学方法会变得绕，而且别人不花点时间根本看不懂这个//33是干嘛的。

所以我的建议是：教学练习阶段老老实实用嵌套把逻辑练熟，工程实践中如果区间本身有规律，优先考虑数学映射。关键是你要能一眼看出一个分段场景属于“有规律可压”还是“无规律可压”。比如评级里“90以上优秀、75到89良好、60到74及格、低于60不及格”就不规整，更适合用嵌套或结构化条件。

5.2 条件列表与函数封装

如果区间边界没有规律，但分支数量很多，又想让代码可读性强一些，可以用一个列表把规则存起来，用循环去匹配。Python下面的写法比较经典：

rules = [ (33, "小数字"), (66, "中等数字"), (100, "大数字"), ] def classify(num, rules): for limit, label in rules: if num <= limit: return label return "超出范围"

这个写法本质上还是顺序判断，但规则和数据分离了。将来要改区间边界，只需要改rules列表，不需要动判断逻辑。这种“表驱动”的思路在配置项多的业务里非常实用。

更进一步，把这整个输入、校验、分类的过程封装成一个函数，可以让主程序变得很薄：

def main(): num = read_valid_number(1, 100) print(classify(num, rules)) if __name__ == "__main__": main()

学会拆函数的意义在于，你把“用户输入”和“业务判断”两个层次解耦了。输入层的代码关心怎么把用户输入变成合法整数，判断层的代码只关心拿到的整数该归到哪个区间。这两个部分将来都可以单独测试、单独修改，互不影响。

5.3 嵌套的合理尺度：三层以上的替代方案

嵌套本身没有罪，罪的是无脑往深了套。如果一段代码里出现三层以上的缩进，我读起来已经需要付出额外的心力去维护一个“状态栈”。第四层、第五层嵌套读起来几乎等于在解一道迷宫。

业界有个常见的经验法则叫“卫语句”：

if num < 1 or num > 100: return "超出范围"

把异常情况在函数开头一个接一个提前返回，剩下的才是主逻辑。用卫语句重写分段判断，就不需要一层套一层：

def classify(num): if num < 1 or num > 100: return "超出范围" if num <= 33: return "小数字" if num <= 66: return "中等数字" return "大数字"

这段代码看起来像平铺，实际上每个if都在隐含地做出范围判断。但它的可读性比嵌套版本强得多，因为每一层条件都是独立的，不用在脑子里维护“前面已经确认过什么”。这也印证了一件事：写作代码时，目标是让下一个人（包括六个月后的自己）阅读起来不吃力，而不是炫技堆嵌套。

今天我带一个新手一步步写完这段判断代码，他最大的收获不是记住if...elif...else的语法，而是看懂了一个判断问题应该怎样分层拆分：先处理输入，再锁定范围，最后细分区间。这个拆解思路本身，比那段示例代码值钱得多。

回到标题本身。如果你正在学编程，我的建议是把这道题做到第三遍：第一遍照着抄，第二遍关掉参考代码自己写，第三遍尝试用卫语句和函数重构。三遍之后，你基本就把条件判断这个地基打得比大多数初学者结实了。等你以后写真实项目，遇到权限校验、状态流转、费用计算这类同样依赖条件分支的业务时，你会发现今天的练习没有白做。