企业官网建设流程全解析

简介：这是一份 Python 经典实例代码合集，共 96 个独立 .py 脚本，压缩包仅 53KB，轻量实用。资源面向编程初学者及进阶开发者，系统覆盖 Python 基础语法、数据类型操作、控制结构、函数与模块、面向对象编程、文件处理、异常机制、数据库交互、网络编程及数据可视化等高频应用场景。实例以 JCP 编号组织，代码简洁、可读性强，便于按需检索与复用。具体包含变量与列表操作、条件与循环、类与继承、SQLite/MySQL 连接、HTTP 请求示例，以及采用 Pandas、Matplotlib 进行数据清洗和图表绘制等代码，能够帮助读者在理解语法之外，掌握实际项目中的排错思路与优化技巧。目前已有 770 人学习下载，既可作为新手系统学习 Python 的实践手册，也可作为开发者日常开发的随身参考，是一份性价比较高的代码锦囊。

1. Python 100例到底是什么：一份能直接跑、也值得反复改的实例库

很多刷过 LeetCode 或翻过教程的人都有同感：语法书看完了，一到自己写项目还是卡壳。这份“Python 经典实例代码汇总 + 100 例”解决的正是这个断层——它不是附在教程最后的练习题，而是按基础语法、经典算法、文件处理、数据清洗、小工具脚本分类组织好的可运行代码。每一段都能直接跑通，也可以拆出来改参数、换输入、嵌进自己的脚本里。适合三类人：正在准备笔试的应届生、需要快速出课设 Demo 的学生、以及写惯了业务代码想补一波算法底子的在职开发者。我的建议是别把它当题库刷，要当零件库用。

2. 按场景选实例：先分清楚“练语法、背算法、做工具”三种用途

拿到 100 个实例，最容易犯的错就是从第 1 例挨个看到第 100 例，看两天就放弃。这个资源最大的价值在于分类，所以第一步是先把目录结构读懂。一般这类代码汇总会按下面几个维度组织，你可以对照自己手上的版本确认：

2.1 选实例的三个原则，避免陷入“看了就忘”

我一般会遵循三条原则来挑实例。第一，目标倒推：先想清楚“我最近要做的事需要哪类代码”，比如你正在整理一批实验数据，那就直奔 CSV 和字典操作；第二，难度半级跳跃：不要选和自己水平完全一致的，选略微超出一点、需要查一次文档才能看懂的实例，这样每吃透一个，能力就向上走一步；第三，每次只深挖一个：把选中的实例从头到尾改三遍，第一遍改参数，第二遍换输入数据，第三遍改函数返回结构，改完才算真正看懂。

2.2 一个高频文件操作实例：批量重命名并保留原后缀

文件批量重命名在 100 例里几乎必出现，而且经常有变体。下面这段是从一个基础实例拆出来的核心逻辑，我加了类型注解和返回值，方便你后续改造。

import os from pathlib import Path def rename_files(folder: str, prefix: str, old_ext: str, new_ext: str) -> int: count = 0 for file in Path(folder).iterdir(): if file.is_file() and file.suffix == old_ext: new_name = f"{prefix}_{file.stem}{new_ext}" file.rename(file.with_name(new_name)) count += 1 return count if __name__ == "__main__": renamed = rename_files("./data", "processed", ".tmp", ".txt") print(f"共重命名 {renamed} 个文件")

这段代码每一处都是可以单独调整的：Path(folder).iterdir()遍历目录但不会递归子目录，如果你要处理子目录，就得换成rglob("*")，这是实例之外最常见的扩展需求。file.suffix取的是扩展名，注意它带点号，所以比较时写.tmp而不是tmp。file.with_name()生成完整新路径，比手动拼接字符串更安全，在 Windows 上尤其能避免反斜杠和正斜杠混用导致的路径报错。

2.3 怎么判断一个实例值不值得深挖

看实例代码最怕的就是“能跑但没感觉”。我给自己定了一个判断标准：能回答出“删掉某一行会怎样”“输入数据如果是空列表会怎样”“这段代码在大数据量下会不会卡”。如果你对着某个实例能提出这三个问题并自己找到答案，这个实例就值得记进自己的笔记；如果看着觉得索然无味，直接跳过，不用有负罪感，毕竟 100 例里真正对你有用的是其中 20 到 30 例。

3. 三个高频模块实战：排序与二分、文件读写、CSV 清洗的完整代码

这一章从 100 例里抽出三个出现频率最高的模块来细讲。选择它们的理由很简单：无论是在笔试环节还是真实业务里，算法、文件和格式化数据都是绕不开的三座山。

3.1 排序与查找：用归并排序练递归和分治

排序在 100 例里通常给出冒泡、插入、归并至少三种写法。其中归并排序最适合用来理解递归与分治，因为它把“拆”和“合”分得很清楚。

def merge_sort(nums: list) -> list: if len(nums) <= 1: return nums mid = len(nums) // 2 left = merge_sort(nums[:mid]) right = merge_sort(nums[mid:]) return merge(left, right) def merge(left: list, right: list) -> list: result = [] i = j = 0 while i < len(left) and j < len(right): if left[i] <= right[j]: result.append(left[i]) i += 1 else: result.append(right[j]) j += 1 result.extend(left[i:]) result.extend(right[j:]) return result

递归出口是len(nums) <= 1，这是最容易写错的地方，有人写成== 0，导致空数组进来时还能跑，但长度为 1 时卡死。注意<=同时覆盖了空列表和单元素列表。mid是数组长度向下取整，切片时左闭右开，所以奇数长度数组也不会漏元素。merge里两个extend是剩下的尾巴，因为两个子数组各自有序，比较完之后剩余的片段直接拼上去就行。

这段代码改造成二分查找也很顺手，把merge换成target比较，递归换成while low <= high，就是标准二分模板。100 例里单独列了二分查找的例子，建议你把这两个对照着看。

3.2 文件读取：批量统计词频时最容易栽的编码坑

文件操作类实例里最常见的是词频统计、日志筛选和编码转换。下面这个单词统计脚本看似简单，但很多人第一次跑就出现乱码或漏词，问题多数出在编码参数上。

def count_words(path: str, encoding: str = "utf-8") -> dict: counter = {} with open(path, "r", encoding=encoding) as f: for line in f: for word in line.strip().split(): counter[word] = counter.get(word, 0) + 1 return counter

encoding参数是玄学高发区。国内下载的 txt 文件常用gbk或gb18030编码，用默认的utf-8打开直接抛UnicodeDecodeError。第 4 章会详细讲这个坑，这里先说结论：面对不确定来源的文件，先以二进制方式读前面几个字节判断编码，或者直接try utf-8 except gbk双保险。另外line.strip().split()会把标点和空格一起切掉，如果统计的是中文文本，这个策略就完全不适用，要改成按正则re.findall切词，这些细节也是实例中不会写出来、但实际用时必然遇到的。

3.3 数据清洗：把 CSV 转成 JSON 并顺带去重排序

数据处理类实例里，CSV 读入到 JSON 输出是一个典型套路。下面这段代码整合了去重、排序、格式转换三个步骤，很适合作为脚本底稿。

import csv import json def clean_csv(src: str, dst: str, key_field: str): seen = set() rows = [] with open(src, "r", encoding="utf-8", newline="") as f: reader = csv.DictReader(f) for row in reader: k = row.get(key_field) if k in seen: continue seen.add(k) rows.append(row) rows.sort(key=lambda r: r[key_field]) with open(dst, "w", encoding="utf-8") as f: json.dump(rows, f, ensure_ascii=False, indent=2)

csv.DictReader会把表头自动作为字典的键，省去手动切分每行字段的麻烦。newline=""是 Python 官方文档明确要求加的，不加的话写入或读取时可能出现多余空行，实例代码里如果不带这个参数，建议你补上。ensure_ascii=False保证中文正常显示，indent=2让生成的 JSON 可读。rows.sort用的是key_field对应的值排序，如果值是字符串且带前导空格，排序结果会偏离预期，所以清洗步骤里最好先做strip()，这属于进阶优化点。

3.4 多文件批量处理：一个遍历目录的通用骨架

很多实例是单文件操作，但实际使用时往往要处理整个目录。下面这个通用骨架是把单文件函数变成批量函数的基本模式：

from pathlib import Path def process_all_files(folder: str, suffix: str, handler): results = [] for path in Path(folder).rglob(f"*{suffix}"): if path.is_file(): result = handler(path) results.append(result) return results

handler是回调函数，你把count_words传进去，它就批量统计词频；把读取首行的函数传进去，它就批量展示文件头。rglob和glob的区别在于是否递归子目录，处理嵌套目录树时用rglob一次到位。这个骨架在 100 例里通常以“遍历目录所有文件”的形式出现，学会之后可以应对大批量文件场景下的重复劳动。

4. 实例跑不通的常见排查：五条高频翻车记录的逐项拆解

实例代码本身能跑，不代表你改完还能跑。这一章整理我在实际使用这份资源过程中反复踩的五类坑，全部按“现象 → 原因 → 解决”的方式记录，遇到问题时直接对号入座。

4.1 编码报错：UnicodeDecodeError 与文本乱码

现象：用open()读取下载的 txt 或 csv 文件，控制台抛出UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb1...；或者读取成功但打印出来全是乱码。

原因：操作系统的默认编码是utf-8，但国内很多历史文件是gbk或gb2312编码，实例代码里一般不会做编码检测，直接按utf-8打开就会崩。如果文件里有中文注释且保存编码本身是gbk，用utf-8读也必挂。

解决：先探测再打开。我自己习惯写一个小工具函数，优先尝试utf-8，失败后回退到gbk：

def smart_open(path: str): for enc in ("utf-8", "gbk", "gb18030"): try: return open(path, "r", encoding=enc) except UnicodeDecodeError: continue raise UnicodeDecodeError(f"无法识别编码: {path}")

如果不想写工具函数，最低成本的方案是先用记事本打开文件另存为 UTF-8，再跑脚本，但文件多了就不现实，建议一次到位。

4.2 路径报错：FileNotFoundError 与反斜杠问题

现象：代码在 Linux 上跑得好好的，放到 Windows 上就报FileNotFoundError，或者路径明明存在却提示找不到文件。

原因：Windows 路径用反斜杠\，而 Python 字符串中\是转义符，直接写"C:\Users\test\data.csv"会被解析成\t、\d等控制字符，导致路径失效。很多实例代码为了避免转义问题，会只写相对路径处理方式，实际使用时照样有人踩。

解决：路径一律用正斜杠或者原生字符串。"C:/Users/test/data.csv"在 Windows 上也能正常工作；或者用Path("C:/Users/test") / "data.csv"。我还习惯在脚本开头打印一遍Path(__file__).resolve().parent，确认当前工作目录不是默认的C:\Windows\System32，很多莫名其妙的路径报错其实都是工作目录没切换导致的。

4.3 高版本文法意外：f-string 与match的兼容问题

现象：拿到实例里写着f"{name=}"或者match ... case的代码，复制到自己环境里报SyntaxError。

原因：这类语法是 Python 3.8 和 3.10 才引入的，而很多实例代码编写时为了兼容老版本不会注明最低版本要求。如果你本地解释器是 3.7，部分新写法直接无法解析。

解决：看代码里是否出现 f-string 的=调试写法或match关键字，出现就确认 Python 版本。实在要跑老环境，把f"{name=}"改成f"name={name}"，match-case改写成if-elif分支。这里也提醒一点，实例是死的，环境是活的，先把python --version查清楚再跑代码。

4.4 列表修改副作用：在遍历时删除元素导致跳过

现象：用for item in lst循环里直接remove某个元素，打印结果发现有些该删的没删掉，有些不该删的却没了。

原因：列表在遍历时是按照索引向后移动的，删除元素后索引自动前移，循环游标没有对应调整，于是每删除一个元素就跳过下一个待检查项。这在算法类实例的“筛选重复项”改写中非常常见。

解决：遍历lst.copy()或切片副本。这是一个安全的通用模式：

lst = [1, 2, 2, 3, 3, 3] for item in lst.copy(): if lst.count(item) > 1: lst.remove(item)

更高效的做法是用列表推导生成新列表，避免原地修改带来的副作用。实例里如果为了展示remove的用法而故意这么写，你理解它就是教学目的，实战中不建议复制。

4.5 递归深度超限：RecursionError 与全局状态污染

现象：跑归并排序或汉诺塔实例时，数据量稍大就抛RecursionError: maximum recursion depth exceeded，或者结果出现不明所以的错位。

原因：递归实例默认递归深度上限是 1000，你传入 2000 个元素时，归并排序的递归树深度会超过上限。错位则多半是因为用了全局变量做临时存储，递归多次调用之间没有清空状态，上一次的残留数据混进了下一次结果。

解决：大数据量改走迭代式归并，或者临时调高递归上限。

import sys sys.setrecursionlimit(10000)

但这块属于“后悔药”，治标不治本，数据量过万还是建议用sorted()或迭代写法。全局状态污染方面，尽量把临时数组作为函数参数传递，不要依赖模块级变量，这也是 100 例里部分递归代码的隐藏问题，初次跑通不代表改场景后还能跑通。

5. 把零散实例改造成工具箱：参数化、组合与批量复用

100 例里的每个实例单独看都是小打小闹，但当你能把两三个实例拼成一个工作流，这份资源就开始产生复利了。这一章讲怎么从“复制粘贴”过渡到“组合改造”。

5.1 第一步：把硬编码参数全部移到函数签名

实例代码为了短小，经常把路径、阈值、文件名写死在代码里。第一步改造就是把它们全部变成函数参数，默认值保持和原实例一致，避免破坏原始行为。

def download_and_clean(url_or_path: str, key_field: str = "id", sort_field: str = "id", remove_dup: bool = True) -> list: rows = load_csv(url_or_path) if remove_dup: rows = deduplicate(rows, key_field=key_field) rows = sort_rows(rows, by=sort_field) return rows

参数默认值让旧调用方式不变，但新增了灵活空间。remove_dup这类布尔开关设计成参数，方便你在不同场景切换。这一步做完，原来的实例就从一个脚本变成可复用函数。

5.2 第二步：把读取、清洗、输出拆成三层

我习惯把组合脚本按“输入 → 处理 → 输出”三层拆分。输入负责读文件和解析格式，处理负责业务逻辑，输出负责落地到文件或打印结果。这样任何一个环节替换实现，其他两层不用动。

df = read_csv(path) # 输入层 df_clean = dedup_and_sort(df) # 处理层 write_json(df_clean, output_path) # 输出层

如果你想换成 Excel 输入，只需替换read_csv这一层实现；想改成直接打印，替换write_json。很多 100 例里的小工具脚本没有按这个结构组织，合到一起就会出现“有的段落在写文件、有的段落又在读文件”的混乱。组合前先按这个标准拆一遍，能避免大量重复代码。

5.3 第三步：验证改造后行为不变化

改造不是重写，最大的风险是把原本正常的行为改没了。我一般会保存一个原始输出作为基准，改造后再跑一遍对比结果，确保逐字节一致或至少逻辑等价。

python old_script.py > before.txt python new_script.py > after.txt diff before.txt after.txt

输出有差异时不要慌，先看是不是排序稳定性带来的顺序差异，再看是不是去重逻辑里set丢失了原始顺序。这两类原因在 100 例的数据清洗变体里经常被混为一谈，如果只是顺序不同而内容一致，可以用sort_before == sort_after再验证一轮。

5.4 沉淀自己的模板文件

改造完后的脚本不要散落在各处。我习惯把每个用顺手的组合脚本收敛成模板，放在一个固定的 tools 目录里，模板头部写清楚输入输出格式和依赖版本。

#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ 功能：通用 CSV 清洗与 JSON 输出 输入：data/*.csv（需包含 id 字段） 输出：out/result.json 依赖：python>=3.8，无需第三方库 """

下次遇到同类任务，直接拷模板改两行就能用，不需要重新翻 100 例去找原始实例。这也是这份资源真正的长期价值：它不只是一次性看的东西，而是你个人代码库的原料来源。

6. 进阶验证：用 pytest 为改过的实例补上测试，锁定功能不退化

改完的组合函数如果没有测试兜底，下次再改动时很容易悄悄破坏行为。pytest 是 Python 生态里最轻量的测试框架，把实例代码里的纯函数加上测试，大概十分钟就能写出一套基础防线。

import pytest from toolset import merge_sort, clean_csv def test_merge_sort_empty(): assert merge_sort([]) == [] def test_merge_sort_duplicates(): assert merge_sort([3, 1, 2, 1]) == [1, 1, 2, 3] def test_clean_csv_dedup(tmp_path): src = tmp_path / "in.csv" src.write_text("id,name\n1,alice\n2,bob\n1,alice\n", encoding="utf-8") dst = tmp_path / "out.json" clean_csv(str(src), str(dst), "id") data = json.loads(dst.read_text(encoding="utf-8")) assert len(data) == 2

测试用例的设计原则是“边界 + 重复 + 极小输入”。merge_sort的空列表和重复元素用例，分别验证了递归出口和稳定排序逻辑；clean_csv用tmp_path创建临时目录而非操作真实文件，避免污染工作区。我在实际工作里会把测试文件和函数放在同一目录下，命名为test_对应模块名.py，运行pytest -v就能看到全部通过情况。

从那以后，我每次从 100 例里挑一个实例下来改，都会强制走一遍这个流程：先标参数化，再拆三层结构，最后补两条测试。这看起来多花十分钟，其实帮你省掉的排查时间远不止这些。有段时间我改了一个日期处理函数，自我感觉没问题，跑了新数据才发现月初第一天全部错位，幸好有旧测试把问题拦在发布之前，那算是我最深刻的一次教训。希望帮到你，也欢迎把你在实例改坑里碰到的好用的技巧整理回这份资源的注释里。

本文还有配套的精品资源，点击获取