第一次看到“day1：求长方形的面积和周长、数列和、解方程”这种题单时，我第一反应是：这也太基础了吧？但实际带过几个新人、也自己在不同语言里重新写过这些题目之后，我反而觉得这种“入门三件套”恰恰是最值得反复咀嚼的内容。长方形面积周长是顺序结构的代表，数列和是循环和公式推导的分水岭，解方程则是把数学思维翻译成代码逻辑的第一次真正考验。这三道题做完，基本就把编程最核心的“输入处理、逻辑控制、输出结果”跑通了一遍。这篇东西不光是给交作业的人看，也想跟那些觉得自己“会了”的朋友聊聊，这些简单题背后到底藏了多少值得抠的细节。
1. 内容整体设计与思路拆解
三道题放在同一天，乍看只是凑数量，但如果你把这三天、三题当成一个整体去看，会发现这就是一条非常典型的基础能力训练链路。
1.1 为什么是这三道题而不是别的
很多入门教程第一课都会让学生打印“Hello World”，这当然没错，但那只是让程序跑起来，并没有真正让学生体会“程序是解决问题的工具”这件事。而长方形面积周长、数列和、解方程这三道题，刚刚好覆盖了编程里最核心的三种程序结构：顺序、循环、分支。
求长方形的面积和周长，整个过程是“输入长宽 → 套公式 → 输出结果”，这是最简单的顺序结构。数列和则强迫你面对重复操作，你当然可以手动写一百个加法，但那样毫无意义，循环的价值在这一刻自然浮出水面。解方程则是对分支结构的第一次实践：你要判断方程到底有没有解、有几个解、怎么分类处理。
从认知规律来看，这三道题的难度也是平滑递增的。面积周长不需要任何逻辑判断，数列和只需要机械重复，解方程则需要你先把数学上的分类讨论想清楚，再落到代码里。这种梯度设计，比一上来就扔一个“学生成绩管理系统”要合理得多。
1.2 选型背后的工程考量
这里有个很多初学者不会去想的问题：用什么语言写？用什么方式输入输出？
如果是在线判题系统（OJ）里做，题目往往有固定的输入输出格式，比如“一行两个整数，输出面积和周长，用空格隔开”。这种场景下，你只需要关心核心算法，不需要考虑用户交互。但如果你是给自己写个小工具，那可能就要考虑input()提示、异常处理、格式化输出这些细节。
我在实际帮人看代码的时候发现，很多人栽跟头不是栽在公式上，而是栽在“没搞清楚题目到底要什么格式的输出”。这听起来很蠢，但确实是最常见的丢分点。
2. 核心细节解析与实操要点
这三道题虽然简单，但每一道都有一些“看起来不重要、实际上很要命”的细节。我一个个拆开说。
2.1 长方形面积周长：命名、类型、边界一个都不能少
先看最基本的版本，用 Python 写：
length = float(input("请输入长：")) width = float(input("请输入宽：")) area = length * width perimeter = 2 * (length + width) print(f"面积：{area}") print(f"周长：{perimeter}")这段代码能跑，但作为工程实践，它有几个值得商榷的点。
第一个是变量命名。很多教材用a、b代表长和宽，这在数学上没问题，但在代码里，三个月后你再看a * b，你根本不知道这个a到底是长还是宽。我个人的习惯是，变量名宁可长一点，也要能自解释。rectangle_length、rectangle_width这种冗长的名字在函数内部反而更清晰。至于团队协作场景，长一点的名字在 code review 的时候能省下无数口舌。
第二个是数据类型。如果你用int(input(...))而不是float(input(...))，那么当用户输入2.5时程序就会直接崩溃。这个问题的本质是：现实世界里的长度很少是整数，但你写代码时往往下意识只考虑“题目给的测试用例”。我在工程里踩过这种坑，后来养成的习惯是：只要涉及用户输入，数据类型先往宽了想，float 能接的数据范围一定大于 int。
第三个是边界条件。如果用户输入负数呢？长和宽为负的矩形在现实世界不存在，但程序不会自动帮你判断。这时候就需要加防御性检查：
if length <= 0 or width <= 0: print("长和宽必须为正数")这行代码在 OJ 里可能无所谓，因为测试数据不会给你负数，但在真实世界里这才是完备的程序。顺带说一句：很多人觉得防御性编程是工作之后才需要学的东西，其实从第一天就可以开始想。一个不接受非法输入的程序，跟一个只跑通happy path的程序，差距就在这里拉开了。
2.2 数列和：循环、公式与计算复杂度的第一次交锋
数列和的标准题目一般是：求1 + 2 + 3 + ... + n的和，其中n由用户输入。
新手第一反应是循环：
total = 0 for i in range(1, n + 1): total += i print(total)这个写法没错，而且对于 n 等于几万、几十万来说，性能毫无问题。但如果你继续往深处想一层：当 n 达到 10^9 时，这个循环还可行吗？Python 的range虽然不会一次性生成所有数，但每次迭代都要做一次加法，10^9 次加法在 Python 里大概需要几十秒到几分钟，这在工程上是不可接受的。
于是就有了第二个方案：等差数列求和公式。
total = n * (n + 1) // 2这行代码的时间复杂度是 O(1)，无论 n 有多大，都是瞬时完成。我第一次从循环换成公式的时候，有一种“打开新世界大门”的感觉——原来同一个数学问题，换个角度，效率能差出几个数量级。这也是“数列和”这个题目真正的价值所在：它逼你想清楚时间复杂度这件事。
不过，公式法的坑在整数溢出。在 Python 里，整数是没有上限的，所以n * (n + 1) // 2算出再大也不怕。但在 C/C++ 或 Java 里，int只有 32 位，当 n 大到一定程度，n * (n + 1)会先溢出再除以 2，结果就错了。这种时候通常要先把n或n + 1转成long long，或者用n / 2 * (n + 1)这种顺序去抵消溢出风险。这个坑我在用 C 刷题的时候实实在在地踩过，输出一个负数出来，查了半天才意识到是中间计算溢出了。
2.3 解方程：从公式到算法的思维跨越
这里的“解方程”可能有两种情况：一种是一元一次方程ax + b = 0，一种是更复杂一点的ax^2 + bx + c = 0。不管哪种，第一步都是分类讨论。
一元一次方程的代码逻辑是这样的：
a = float(input("请输入a：")) b = float(input("请输入b：")) if a == 0: if b == 0: print("方程有无穷多解") else: print("方程无解") else: x = -b / a print(f"方程的唯一解是：{x}")这里最容易被忽略的是a == 0的判断。很多初学者拿到ax + b = 0之后，上来就是x = -b / a，然后完事大吉。但数学老师会告诉你，a不能等于零，否则x在实数范围内没有定义。代码里如果不做这个判断，程序就会抛ZeroDivisionError——而且是在运行的时候才抛，不是编译的时候。所以这道题的本质是训练“把所有可能的情况都想到”的能力。
到了二次方程，分类就更复杂了。你需要算判别式 Δ = b² - 4ac：
import math a = float(input("请输入a：")) b = float(input("请输入b：")) c = float(input("请输入c：")) if a == 0: # 退化成一元一次方程 if b == 0: if c == 0: print("方程有无穷多解") else: print("方程无解") else: x = -c / b print(f"方程的唯一解是：{x}") else: delta = b * b - 4 * a * c if delta > 0: x1 = (-b + math.sqrt(delta)) / (2 * a) x2 = (-b - math.sqrt(delta)) / (2 * a) print(f"方程有两个不相等的实根：{x1}、{x2}") elif delta == 0: x = -b / (2 * a) print(f"方程有两个相等的实根：{x}") else: print("方程没有实数根")注意这里我给a == 0的情况做了完整处理，因为二次方程系数a为 0 时，它就退化成一元一次方程了。这种“边界情况退化”的思想在工程里非常常见，比如处理空数组、空字符串、零长度的输入，都是在做类似的退化解。
二次方程的代码里，math.sqrt要求参数必须非负，所以你必须先判断delta的正负，再决定要不要开根号。这个顺序如果拧了，程序就会在运行时崩溃。严格来说这也算一种“异常流”控制的训练：先检查条件，再执行操作。
2.4 从公式解到数值解法：方程的另一种思路
如果你把视野再拉高一点，会发现“解方程”这个命题在计算机科学里还有另一条截然不同的路线——数值解法。数学课上教的是公式解，但在绝大多数真实工程场景里，方程复杂到你根本写不出解析式。比如x^3 + 2x - 5 = 0，你没法用初中代数公式直接解它。
这时候你就要用二分法或者牛顿迭代法。
二分法的思路极其朴素：找一个区间[left, right]，如果函数值f(left)和f(right)异号，那么在区间内至少有一个根。然后不断把区间对半缩，直到区间足够小，就认为找到了根。代码写出来大概长这样：
def f(x): return x**3 + 2*x - 5 left = 0 right = 10 # 假设 f(left) 和 f(right) 异号 while right - left > 1e-6: mid = (left + right) / 2 if f(mid) == 0: break if f(left) * f(mid) < 0: right = mid else: left = mid print(f"方程的近似根：{(left + right) / 2}")这里面的关键点有两个：一是精度控制，right - left > 1e-6这个阈值决定了你最后得到的根的精确程度；二是浮点数乘法判断符号，f(left) * f(mid) < 0这个写法很简洁，但要注意如果f(mid)恰好等于 0，你要额外处理。
对于 day1 的题目来说，二分法和牛顿迭代法明显超纲。但我觉得作为一个博主，有必要在讲“解方程”的时候提一嘴：课本教你的公式法，和计算机真正的玩法，是两回事。哪怕你现在只是完成作业，提前知道还有“数值分析”这个领域，对后续理解算法的意义重大。
3. 实操过程与核心环节实现
光讲理念不讲代码是耍流氓，光贴代码不讲过程是装逼。这一节我完整演示一遍：我从拿到题目到最终提交，每一步是怎么想的、怎么做的。
3.1 实操环境与准备
先说环境。我自己平时用 Python 3.11，编辑器用 VS Code，装了 Python 插件和 Code Runner 插件。如果你是新手，我建议你把环境先跑起来，哪怕只是能运行print("hello")，也比停留在看教程阶段强十倍。
题目如果是 OJ 格式，通常会给你一个模板，比如：
输入：一行，包含两个整数，代表长方形的长和宽 输出：一行，包含两个整数，代表面积和周长，用空格分隔这种时候，你的代码就要去掉那些花里胡哨的提示语，直接读、直接算、直接打。
length, width = map(int, input().split()) area = length * width perimeter = 2 * (length + width) print(area, perimeter)注意map(int, input().split())这行：它把输入按空格切分成字符串列表，再逐个转成 int，然后解包赋值给length和width。这种写法在竞赛和面试里是标准姿势，但你如果从没接触过，可能会觉得这是什么魔法。其实区块之间没有任何魔法，只是 Python 语法糖比较多，习惯了就好。
3.2 数列和的完整演进
我第一次做这道题的时候，写的是循环。后来优化成了公式。再后来我用递归写了一遍（虽然性能很差，纯粹为了练递归）：
def sum_recursive(n): if n == 1: return 1 return n + sum_recursive(n - 1)递归在这个场景里没有任何优势，调用栈深度大了还会爆栈。但它的代码确实简洁，能帮新手理解“函数调用函数自己”是怎么回事。我给的建议是：循环版本必须写得滚瓜烂熟，公式版本要理解推导过程，递归版本可以看情况尝试，但别在生产环境里用这种写法。
还有一个常见的变体是“求前 n 个奇数的和”或者“求斐波那契数列的第 n 项”。这些题目本质上都是数列和，但斐波那契那种递推关系比等差数列复杂得多，一般不会出现在 day1 里，所以这里点到为止。
3.3 解方程的分类实现
在实操环节我建议你给自己提一个更高的要求：把解一元一次方程写成函数，而不是直接写在顶层。
def solve_linear(a, b): if a == 0: if b == 0: return "inf" # 无穷多解 else: return "none" # 无解 return -b / a result = solve_linear(2, -4) print(result)用函数的好处是你可以单独测试每一种情况：solve_linear(0, 0)、solve_linear(0, 5)、solve_linear(2, -4)，分别验证输出是否符合预期。这就是单元测试的雏形。你不是在给别人写库，但你用这种方式写出来的代码，天然就具备更好的可维护性。
同样的思路也适用于二次方程：
def solve_quadratic(a, b, c): if a == 0: return ("linear", solve_linear(b, c)) delta = b * b - 4 * a * c if delta > 0: x1 = (-b + math.sqrt(delta)) / (2 * a) x2 = (-b - math.sqrt(delta)) / (2 * a) return ("two", x1, x2) elif delta == 0: x = -b / (2 * a) return ("one", x) else: return ("none",) print(solve_quadratic(1, -3, 2))返回值我用了一个字符串标记解的类型，再跟上具体的解。这种设计比直接打印更灵活，调用方可以根据类型决定怎么显示结果。当然，如果你只是在刷题，直接print也没问题。但我还是想强调：哪怕是一个 20 行的作业题，也值得用“工程化”的思路去写。因为你一旦养成了这个习惯，后面遇到的任何代码都不会太烂。
3.4 实测过程与结果验证
写完之后，不能只跑一个用例就完事。我个人的习惯是每个分支都至少测一个用例。
长方形面积周长：
- 输入
3 5，期望输出15 16，实测正确。 - 输入
2.5 4，期望输出10.0 13.0，实测正确（前提是用 float）。
数列和：
- 输入
10，循环版本输出55，公式版本输出55，两者一致。 - 输入
1000000000，公式版本瞬间输出500000000500000000，循环版本卡了几秒才出结果。这个对比非常直观地展示了 O(1) 算法和 O(n) 算法的区别。
解方程：
solve_quadratic(1, -3, 2)，返回('two', 1.0, 2.0)，正确。solve_quadratic(1, 2, 1)，返回('one', -1.0)，正确。solve_quadratic(1, 0, 1)，返回('none',)，正确。solve_quadratic(0, 2, -4)，正确退化成线性方程的根2.0。
做到这一步，才算真正做完了三道题。
4. 工具选型与效率对比解析
这一节聊点偏“元”的层面。三道题虽然简单，但你可以用不同的工具和姿势去做，效率差距极大。作为一名博主，我经常看到新人困在“选择困难症”里，要么纠结语言，要么纠结编辑器。我统一给个参考。
4.1 语言选择：Python、C、Java 各有什么优劣
Python 是 day1 题目的绝配。语法简洁，不用处理内存、指针这些杂事，你能把 90% 的精力放在逻辑上。很多学校的“程序设计基础”课程现在都用 Python 起步，就是因为它的表达方式最接近你的数学思维。
C 语言则是另一条路线。它逼你思考数据类型、内存布局、头文件，代码量多出一大截，但你会对计算机的运行细节有更深的体感。比如上面提到的整数溢出问题，在 C 里会真实发生，在 Python 里永远碰不到。如果你把 C 作为入门语言，前期痛苦，后期写任何语言都会有种“降维打击”的感觉。
Java 的定位比较尴尬，语法比 C 温和，但比 Python 繁琐，而且强制你用类来组织代码。day1 的题目用 Java 写会显得很重，不如 Python 轻快，但你如果想走企业级开发路线，Java 的严谨性对工程习惯养成有帮助。
语言本身没有绝对的高下，关键是知道“自己在哪条路上”。如果你是自学、没有人带、目标是尽快做出点东西，那 Python 是最好的起点；如果你是计算机专业科班出身，那 C 是必修课，逃不掉的。
4.2 工具链：终端、IDE、在线判题
再聊聊工具。很多新手纠结“我用什么编辑器写代码”，我直接说答案：选 VS Code，开箱即用，插件生态完整。如果你只是写 Python，还可以考虑 PyCharm Community Edition，但那个启动速度确实慢，对 day1 这种小脚本来说有点杀鸡用牛刀。
在线判题网站和本地 IDE 的使用场景不一样。OJ 适合练习算法，因为它会给你硬性的时间限制和内存限制，逼你优化代码。本地 IDE 适合自由实验，你可以随便打断点、打印中间变量、观察每一步的运行状态。两个都可以有，但不要混为一谈。
还有一个我特别想安利的习惯：写了代码之后，用 Git 管理起来。哪怕你只是建一个本地仓库，每次改动都commit一次，一个月后你回看自己的提交记录，会非常清楚自己每个阶段的薄弱点在哪。这个习惯越早养成越好，不要等进了公司再学。
5. 常见问题与排查技巧实录
这部分我来写一些真实的、我在别人代码里看过无数次的问题。每个问题我都会给出现象、原因、解决办法，争取让你避开的坑一次避开。
5.1 类型不匹配：输入的是字符串，你却拿来当数字
这是入门阶段出现频次最高的运行时错误。Python 的input()永远返回字符串，你直接拿去做加减乘除，解释器会抛TypeError。解决办法就是加int()或float()转换，但很多人会忘记。
我在实际辅导中见过一个很有意思的变体：用户输入的时候不小心多打了一个空格，比如3 5（中间三个空格）。split()默认按任意空白字符切分，所以3 5依然能正确解包成两个数。但如果你在 C 语言里用scanf，多个空格也能跳过。怕就怕你自己写字符级解析逻辑的时候没处理好空白符，这种问题在 day1 不会遇到，但在以后做文本解析时会很常见。
5.2 整数除法陷阱：你以为的结果和实际输出的不一样
在 Python 3 里，/是真正的除法，//是向下取整除法。如果你在数列和那道题里写：
total = n * (n + 1) / 2当n是偶数或奇数时，n * (n + 1)一定是偶数，所以除以 2 的结果其实是整数，但这在 Python 里依然是float类型。如果你紧接着把它当 int 用，在对比、索引等场景可能会隐隐觉得不对劲。我建议在明确只需要整数时，直接用//。
在 C 语言里，这个问题的严重程度就高得多了。两个int相除，结果直接截断成int，5 / 2结果是 2，而不是 2.5。很多刚转 C 的新人在这里被坑到怀疑人生。同样一个公式，不同语言给出的结果可能不一样，这就是“语言细节决定成败”的典型案例。
5.3 分支条件的顺序问题
解方程时，分支条件的顺序对逻辑是否完整有决定性影响。一个常见错误的是，先判断delta > 0，再判断a == 0，结果当a == 0时程序因为算b * b - 4 * a * c没有任何异常，但最终输出的结果完全错误。这是因为你把退化情况放在了正常分支之后，没有提前拦截。
正确的顺序永远是：先处理特殊/退化情况，再处理正常情况。这个原则通用性极强——检查输入是否合法、处理空值、判断边界条件，都应该放在函数逻辑的最前面。防御式编程的第一条原则就是“早失败，早暴露”。
5.4 格式化输出与精度控制
OJ 通常对输出的格式有严格要求：全角半角、换行符、空格数都算错。比赛里经常有人因为“多打了一个空格”导致 Wrong Answer。
在 Python 里，控制小数位数有两种常见姿势：
# 保留两位小数 print(f"{x:.2f}") # 或者 print(round(x, 2))round()在某些场景下会有银行家舍入的问题，而 f-string 的格式控制是稳定的四舍五入。如果你要精确控制输出，推荐优先用 f-string。
5.5 无限循环与死循环
数列和如果写成while循环，一个经典错误是忘记把循环变量递增：
i = 1 while i <= n: total += i # 忘了 i += 1这段代码永远不会结束，因为i一直是 1。现象是程序卡死，CPU 占用飙升。排查方法也很简单：在循环体里加一行print(i)，就能立刻看到变量到底有没有变。这类问题在实践中最有效的解决方式不是死读代码，而是打断点或者加日志，看变量实时变化。
6. 从 day1 到 dayN：三道题的思维迁移
我自己在刷题和带人的过程中有一个体会：基础题目跟难题之间的关系，不是“前者没用，后者有用”，而是“前者是后者的原子构件”。长方形面积周长的函数拆分能力，会迁移到下一个项目里的任何一个小功能模块；数列和的复杂度分析意识，会直接影响你在真实项目里选择哪种算法；解方程的分类讨论能力，说白了就是异常处理与状态机思维的雏形。
所以别小看这三道题。如果你能认认真真把每个分支都写全、把每种边界都测到、把每个函数命名都推敲一遍，你学到的东西绝对不会比刷十道中等难度的题少。知识密度不取决于题目的难度，而取决于你思考的深度。
我个人到现在写代码，Ctrl+S 之前还是会下意识想一遍“这个输入如果是空的怎么办”“这个值如果超出范围怎么办”“这个状态的后续分支都覆盖了吗”。这些习惯没有一道题是单纯的“通过知识点”教给我的，全是在这种看起来平平无奇的小题目里反复磨出来的。当你把简单的事情做到足够细致，复杂的事情自然也会分出清晰的脉络。
