企业官网建设流程全解析

简介：一份基于Python实现的密码强度检查器源码包，面向Python初学者与安全相关开发者，用于快速评估用户密码的复杂度并给出改进建议，可直接应用于登录注册模块的密码校验，也可作为安全测试练习的小型项目。压缩包仅4KB，包含5个文件：核心py脚本负责强度判断，requirements.txt列出运行依赖，README.md提供使用说明，LICENSE与.gitignore则便于分发与版本管理，整体结构精简，适合直接阅读、调试和二次开发。目前已有954人学习下载。借助该工具源码，读者可以理解密码强度检查的常见维度（如长度、字符种类、重复片段等），学会如何组织小型Python工具项目，并在此基础上扩展自定义规则或集成进自己的应用，增强账号安全防护能力。

1. 密码强度检查器：为什么"看起来很强"的密码往往最脆弱

把"密码强度检查器"做成一个 Python 小工具，几乎是每个安全方向开发者绕不开的练手题。但如果你只按"长度 + 字符种类"打分，做出来的东西大概率跟没做一样。我见过不止一次：用户输入P@ssw0rd123，新手写的检查器直接判定"强"，可这个字符串早就躺在各类弱密码排行榜前列，机器用字典跑一遍，几秒钟就拿下。真正能落地的密码强度检查器，核心不是检查"花哨程度"，而是估算"破解成本"。这背后涉及搜索空间、熵值、字典攻击、键盘序列等一系列问题，任何一个环节想当然，都会让分数失真。这篇文章就用一个可复现的 Python 实现把这些问题逐个拆开，适合安全方向开发者、后端工程师，以及所有想给自家系统加一道密码校验的人。

2. 密码强度模型：搜索空间、熵值与破解成本

2.1 搜索空间：为什么"长度"比"字符种类"更值钱

先明确一个基本公式：暴力破解的搜索空间大小是字符集大小的长度次方。假设字符集大小为 L，密码长度为 n，那么候选密码总数就是 Lⁿ。攻击者逐个尝试时，平均尝试次数大约为搜索空间的一半，时间成本由尝试速度决定。

举个例子就非常直观：

• 8 位纯小写密码：26⁸ ≈ 2.09 × 10¹¹，普通 GPU 每秒可尝试数十亿次，几分钟内就能跑完。
• 8 位混合大小写加数字：62⁸ ≈ 2.18 × 10¹⁴，比纯小写多了约三个数量级。
• 12 位混合大小写加数字：62¹² ≈ 3.22 × 10²¹，即使顶尖算力也需要数年。

对比下来你会发现，从 8 位提升到 12 位带来的安全增益，远大于把字符集从 26 扩展到 62。这也是为什么近几年的密码策略普遍把"最小长度"放在第一位，而对"必须包含特殊字符"这类要求反而在弱化。

我在实际项目中一般会同时看两个指标：一个是字符集大小对应的理论熵，另一个是密码长度本身。单纯要求"必须有大写、小写、数字、特殊字符"，用户很容易拼出Abc@1234这种满足全部规则却毫无随机性的密码；反过来，correct-horse-battery-9这种较长的短语，虽然只用了小写字母和数字，实际破解成本反而高得多。

还有一个经常被忽略的点：字符集大小应该按"用户实际可能用到的字符类型"来估算，而不是按用户输入里出现了多少种字符来算。比如用户输入abc123，字符集是 26 + 10 = 36，搜索空间是 36⁶；如果你只按"出现小写和数字两类"粗略当作 62⁶，那就高估了。正确做法是扫描整串字符，去重后统计实际出现的字符范围。

2.2 熵值估算：Shannon 熵与密码强度的关系

信息论里，熵用来衡量不确定性。对于一个均匀随机选择的密码，它的理论熵就是搜索空间取以 2 为底的对数：H = log₂(Lⁿ) = n × log₂(L)。这个值表示"要完全确定这个密码，平均需要多少个二进制比特"。

按这个公式估算：

• 8 位纯数字：8 × log₂(10) ≈ 26.6 比特
• 8 位混合大小写加数字：8 × log₂(62) ≈ 47.6 比特
• 12 位混合大小写加数字：12 × log₂(62) ≈ 71.4 比特

行业里常见的参考基线是：熵值在 28 比特以下视为极弱，28 到 50 比特属于可短时间破解，50 比特以上才算具备基本抵抗离线攻击的能力。有些内部系统会要求新密码熵值不低于 40，这个数字本身没有绝对标准，但它给了我们一个可以量化的门槛。

但这里有个大坑：上述公式假设用户是从字符集里均匀随机选取字符。真实用户不会这样做——他们的大脑天然偏向可记忆的模式，比如名字加生日、键盘连续按键、常见单词加数字后缀。一个看起来符合"大小写+数字+符号"的密码，实际熵可能远低于理论值。P@ssw0rd1按公式估算有 8 × log₂(72) ≈ 49 比特，但它的生成规则太常见，实际有效熵可能不到 20 比特。

所以，我一般把熵值计算当作"搜索空间的下限检查"，而不是"最终结论"。真正决定强度判断的，是接下来要说的启发式规则：弱口令库、键盘序列、语义模式。这也符合近几年的安全建议——不再迷信字符组合要求，而是更关注"是否容易被猜到"。

2.3 分级阈值设计：从分数到"拒绝 / 警告 / 通过"

有了熵值和规则命中情况后，需要把它们综合成一个可执行的判断结果。常见做法是输出 0 到 100 分，外加一个等级：

这个分级表不是标准答案。有的业务场景只需要三档，有的则需要把"警告"再拆成"建议修改"和"必须修改"。我习惯把阈值设计成配置项，而不是硬编码，因为不同系统的安全等级差异很大：内部 OA 系统的密码策略，不需要跟金融核心系统一样苛刻。

另外还有一个设计决策：检查器不应该只返回一个分数。分数是给程序判断用的，用户更需要的是"为什么不够强"。"缺数字""命中了常见弱密码""出现了键盘连续字符"这类信息，才是用户真正愿意照着改的指引。不过具体反馈到什么粒度，后面讲避坑时再说，这里先记住一个原则：反馈要够用，但不要过度暴露判断逻辑。

3. 用 Python 实现最小可用的密码强度检查器

3.1 基础结构：字符集识别与长度统计

先从最基础的部分开始：识别密码中出现的字符类型，并统计长度。这一步是后续所有计算的地基。

def classify_charsets(password: str) -> dict: """ 统计密码中实际出现的字符类型，返回各类字符的数量。 返回字典包含： - lowercase: 小写字母数量 - uppercase: 大写字母数量 - digits: 数字数量 - symbols: 其他可见符号数量 - spaces: 空格数量 - unicode_letters: 非 ASCII 字母数量（如中文、日文等） """ import unicodedata counts = { "lowercase": 0, "uppercase": 0, "digits": 0, "symbols": 0, "spaces": 0, "unicode_letters": 0, } for ch in password: if ch.isdigit(): counts["digits"] += 1 elif ch.isspace(): counts["spaces"] += 1 elif ch.islower(): counts["lowercase"] += 1 elif ch.isupper(): counts["uppercase"] += 1 else: # 非 ASCII 字母、符号等统一处理 if unicodedata.category(ch).startswith("L"): counts["unicode_letters"] += 1 else: counts["symbols"] += 1 return counts

这段代码有几个细节值得说明。ch.islower()和ch.isupper()只对 ASCII 字母和已经区分大小的 Unicode 字符返回 True；中文字符两个方法都会返回 False，所以需要再判断unicodedata.category是否以 "L" 开头，才能归入unicode_letters。如果不做这一步，中文密码会被错误归类到 symbols，导致字符集估算偏差，后面讲避坑时会展开说。

unicode_letters单独计数，而不是塞进symbols，是因为中文字符的"字符集大小"估算方式跟英文字母完全不同：中文常用字有几千个，如果把每个汉字都算作符号，那字符集大小会被低估好几个数量级。

def estimate_charset_size(counts: dict) -> int: """ 根据字符类型统计，估算实际字符集大小。 采用保守估计：只把"明确存在"的字符范围计入。 """ charset_size = 0 if counts["lowercase"] > 0: charset_size += 26 if counts["uppercase"] > 0: charset_size += 26 if counts["digits"] > 0: charset_size += 10 if counts["symbols"] > 0: # 符号集合取常见可打印符号的保守范围 charset_size += 32 if counts["spaces"] > 0: charset_size += 1 if counts["unicode_letters"] > 0: # 中文字符按常用 3500 字估算，而不是所有 Unicode 汉字 charset_size += 3500 return charset_size

这里采用的是一种"可用惯例"：常见可打印 ASCII 符号按 32 个估算，中文按常用汉字 3500 估算。如果你需要更精确，可以用string.printable去重后计算符号数量，但作为检查器没必要那么精确，因为真正的强度判断不靠单独字符集大小，而是由后续规则综合决定。保守估计的意义在于：宁可按偏小的搜索空间算，也不能高估。

3.2 熵值计算函数

有了字符集大小和长度，理论上限熵就可以直接计算了。

import math def theoretical_entropy(password: str, counts: dict) -> float: """ 计算密码的理论熵（比特）。 公式：H = n * log2(L) 其中 n 为密码长度，L 为估算的字符集大小。 """ charset_size = estimate_charset_size(counts) length = len(password) if charset_size <= 1 or length == 0: return 0.0 return length * math.log2(charset_size)

这个函数很直白，但注意它对"模式化密码"完全不设防。aaaaaaaaaa这个密码，长度 10，小写字符集 26，理论熵 10 × log₂(26) ≈ 47 比特，如果我们只看熵值会认为"中等偏上"，但实际它脆弱得不堪一击。所以理论熵只能作为参考基线，真正的降分逻辑来自后面的规则检测。

组合起来，我们可以得到一个基础打分函数：

def basic_score(password: str) -> dict: """ 返回一个包含字符集统计、理论熵、长度信息的字典。 """ counts = classify_charsets(password) entropy = theoretical_entropy(password, counts) length = len(password) return { "length": length, "counts": counts, "entropy": entropy, }

basic_score的结果会作为后续规则检测的输入。每个规则模块返回一个"扣分点"或"命中标记"，最后由汇总函数计算最终分数。这种设计把核心逻辑和规则逻辑解耦，后面加新规则时不需要改动熵值函数。

3.3 打分与等级判定

打分逻辑可以有很多版本，下面这个是我实践下来比较稳定的一套，兼顾了理论熵与模式惩罚。

def final_grade(result: dict) -> str: """根据最终分数返回等级。""" score = result["score"] if score < 40: return "极弱" elif score < 60: return "较弱" elif score < 80: return "中等" else: return "较强" def compute_final_score(basic: dict, penalties: list, bonuses: list = None) -> dict: """ basic: basic_score 返回的字典 penalties: 规则命中产生的扣分项列表，每个元素是 (说明, 扣分数) bonuses: 额外加分项，可选 """ score = 100.0 # 基础分：以长度和熵为起点 length = basic["length"] entropy = basic["entropy"] # 长度不足直接拉低基线 if length < 8: score -= (8 - length) * 8 elif length >= 16: score += 5 # 长密码给一点鼓励分，但不超过 100 else: score += (length - 8) * 2 # 熵值调整：不足 40 比特按比例扣 if entropy < 40: score -= (40 - entropy) * 1.2 # 应用规则扣分 for desc, penalty in penalties: score -= penalty # 应用加分 if bonuses: for desc, bonus in bonuses: score += bonus # 归一化到 0-100 score = max(0.0, min(100.0, score)) return { "score": round(score, 1), "grade": final_grade({"score": score}), "penalties": [p[0] for p in penalties], "bonuses": [b[0] for b in bonuses] if bonuses else [], "entropy": round(entropy, 2), "length": length, }

打分参数说明：

这个打分体系的思路是"先给一个基准分，再逐项扣分"。它比纯阈值判断更平滑，也更容易向用户解释：为什么这个密码不合格？因为命中了两条规则，扣了 40 分。注意，打分规则是启发式的，没有绝对正确的版本，你的业务方如果有安全合规要求，应当以合规要求为准来调整参数。

4. 让检查器更像一线工具：弱口令库、键盘序列与语义规则

4.1 内置弱口令库：命中即降级

理论熵再高，也架不住用户使用人尽皆知的密码。弱口令库是强度检查器性价比最高的一层防线。常见做法是内置一份 Top 100 或 Top 1000 的弱密码清单，注册校验时先做哈希或 Set 查找。

# 一个极简的 Top 弱口令片段，实际使用时应加载完整的 Top1000 列表 COMMON_WEAK_PASSWORDS = { "123456", "password", "12345678", "qwerty", "123456789", "12345", "1234", "111111", "1234567", "dragon", "123123", "baseball", "abc123", "football", "monkey", "letmein", "696969", "shadow", "master", "666666", "qwertyuiop", "123321", "mustang", "1234567890", "michael", "654321", "pussy", "superman", "1qaz2wsx", "7777777", "fuckyou", "121212", "000000", "qazwsx", "123qwe", "killer", "trustno1", "jennifer", "zxcvbnm", "asdfgh", "hunter", "busted", "harley", "batman", "andrew", "tigger", "sunshine", "iloveyou", "fuckme", "2000", "charlie", "robert", "thomas", "hockey", "ranger", "daniel", "starwars", "klaster", "112233", "george", "asshole", "computer", "michelle", "jessica", "pepper", "1111", "zxcvbn", "555555", "11111111", "131313", "freedom", "777777", "pass", "fuck", "maggie", "159753", "aaaaaa", "ginger", "princess", "joshua", "cheese", "amanda", "summer", "love", "ashley", "6969", "nicole", "chelsea", "biteme", "matthew", "access", "yankees", "987654321", "dallas", "austin", "thunder", "taylor", "matrix", "william", "corvette", "hello", "martin", "heather", "secret", } def check_weak_password(password: str) -> bool: """直接判断密码是否命中弱口令库。""" return password in COMMON_WEAK_PASSWORDS

但直接比较有个明显漏洞：P@ssw0rd不在上面这个列表里，可它本质就是password的字符替换变体。真正的弱口令检测需要做"变体归一化"——把@替换成a、0替换成o、1替换成i或l、$替换成s，然后再去和弱口令库匹配。

LEET_MAP = { "@": "a", "0": "o", "1": "i", "!": "i", "$": "s", "5": "s", "3": "e", "4": "a", "7": "t", "+": "t", "9": "g", "8": "b", "2": "z", "6": "g", } def normalize_by_leet(password: str) -> str: """将常见 leetspeak 替换还原为字母，再做小写处理。""" normalized = [] for ch in password.lower(): if ch in LEET_MAP: normalized.append(LEET_MAP[ch]) else: normalized.append(ch) return "".join(normalized)

normalize_by_leet的处理策略是逐字符映射：先把整个字符串小写化，再把数字和符号替换成对应字母。注意这个映射表不能太激进，否则会把正常密码也误判成弱口令。比如用户密码是happy2024，还原后变成happyz024，不会命中弱口令库，但p@ssw0rd还原成password就会精准命中。这个"适度替换"的度，需要你根据自己的用户群体微调映射表。

4.2 键盘序列与重复字符检测

键盘序列是另一类高频弱密码来源。用户倾向于直接划键盘上相邻的一行键，比如qwertyuiop、asdfghjkl、zxcvbnm，或者对角序列1qaz2wsx、zaq12wsx。这类密码即使带数字和字母混合，也毫无随机性可言。

检测思路很简单：定义键盘上的连续序列字符串，在密码里搜索是否存在长度 ≥ 3 的连续子串命中这些序列。

KEYBOARD_SEQUENCES = [ "qwertyuiop", "asdfghjkl", "zxcvbnm", "1qaz2wsx", "qazwsx", "zaq12wsx", "1q2w3e4r5t", "yhnujmikl", "poiuytrewq", # 反向 "mnbvcxz", "lkjhgfdsa", # 反向 ] def detect_keyboard_pattern(password: str) -> list: """ 返回命中的键盘序列片段列表。 将密码转小写后，在键盘序列中逐一查找连续子串。 """ lower_pwd = password.lower() hits = [] for seq in KEYBOARD_SEQUENCES: # 滑窗：从 4 字符开始匹配，命中后继续减少窗口 for length in range(min(4, len(seq)), 2, -1): for i in range(len(seq) - length + 1): fragment = seq[i:i + length] if fragment in lower_pwd: hits.append(fragment) return hits

这段代码用了一个滑窗思路：对每个预设的键盘序列，从 4 字符长度的子串开始，逐一切片到原始密码里查找。使用从大到小的窗口是为了避免重复命中后产生过多扣分，而且 3 字符及以上的连续序列才值得扣分，两个字母比如qw太泛了，误报率高。测试中发现1qaz2wsx这类 8 字符序列会被完整命中，扣分力度直接拉满，效果比人工枚举正则好得多。

重复字符检测就更简单了：

import re def detect_repeated_chars(password: str, threshold: int = 3) -> list: """ 检测重复字符块，返回重复片段列表。 例如 'aaaaaa' 会命中 'aaaa'，'1111' 会命中 '1111'。 """ pattern = re.compile(r"(.)\1{" + str(threshold - 1) + r",}") matches = pattern.findall(password) return [match * threshold for match in matches]

正则(.)\1{n-1,}匹配同一个字符连续出现至少 n 次。这里 threshold 设为 3，意味着aaa就已经触发降级。有些检查器把 threshold 设为 4，理由是三位重复在正常密码里偶尔会出现，比如bookkeeper里的kk和ee；但三位以上连续重复基本可以断定是用户随手敲的。这个阈值你可以自己调，我习惯用 3，因为密码中出现三位重复的概率本身不算低，扣分能迫使用户改掉一个明显的弱点。

4.3 语义规则：生日、手机号、用户名反向

第三类高频弱密码来自个人信息。生日、手机号、用户名反向是前三名。这些规则不复杂，但效果立竿见影，尤其在后端接口场景下，因为服务端往往已经掌握了用户的注册信息。

import datetime def detect_personal_info(password: str, username: str = "", extra_keywords: list = None) -> list: """ 检测密码中是否包含生日、手机号、用户名等个人信息。 返回命中的规则描述列表。 """ hits = [] lower_pwd = password.lower() # 1. 年份检测：19xx 或 20xx year_match = re.search(r"(19\d\d|20\d\d)", password) if year_match and year_match.group(0): hits.append("包含出生年份或近期年份") # 2. 日期检测：如 19900101、1990-01-01、900101 date_match = re.search( r"((19\d\d|20\d\d)[\-\./]?\d{1,2}[\-\./]?\d{1,2})|(\d{6,8})", password ) if date_match: hits.append("包含疑似日期信息") # 3. 手机号检测：11 位数字且以 1 开头 if re.search(r"1[3-9]\d{9}", password): hits.append("包含疑似手机号") # 4. 用户名检测：用户名长度 >= 3 且按原序或倒序出现在密码中 if username and len(username) >= 3: lower_user = username.lower() if lower_user in lower_pwd or lower_user[::-1] in lower_pwd: hits.append("包含用户名信息") # 5. 额外关键词检测：公司名、产品名等 if extra_keywords: for kw in extra_keywords: if kw.lower() in lower_pwd: hits.append(f"包含关键词: {kw}") break return hits

这个函数返回的是"命中描述"而不是命中对象，因为后续打分只需要知道有没有这回事、该扣多少分。年份检测单独一个正则，是因为1990或2024这种四位数年份在密码里太常见，且用户极大概率用的是自己的出生年；日期检测的正则稍微宽松，覆盖了19900101、1990-01-01、900101三种常见写法。手机号正则1[3-9]\d{9}匹配中国大陆 11 位手机号，其他地区的号码格式需要自行调整正则。

关键词检测的extra_keywords参数建议传入公司的域名前缀、产品名或项目代号。比如某内部系统叫某跨平台系统，用户可能会用mouplatform2024当密码，这种密码理论熵不低，但一旦业务方知道系统名，猜测成本极低。这类规则在一个组织内部非常好用，因为攻击者本来就会优先尝试这些词。

5. 密码强度检查器避坑指南：五个容易翻车的边界细节

5.1 翻车一：Unicode 中文字符的字符集误判

现象：用户输入 8 位中文密码，比如安全第一哦，检查器给出的熵值不到 30 比特，被判定为"极弱"。但实际这 8 个汉字是从几千个常用汉字里选出来的，搜索空间并不小。

原因：代码里用了ch.islower()和ch.isupper()判断字符类型，中文字符两者都返回 False，于是被丢进了symbols分支，按 32 个符号来估算字符集大小。8 位密码乘以 log₂(32) ≈ 40 比特，勉强中等；如果撞上更严格的口径，可能直接判定不合格。

解决：字符分类时必须单独处理非 ASCII 字母。我给出的classify_charsets函数里用unicodedata.category(ch).startswith("L")来识别任何字母字符，包括中文、日文、韩文。中文部分再单独估算字符集大小，建议按常用汉字 3500 个计算，而不是用所有汉字 70000 多个，因为用户能记住的汉字大概率只是常用字。两者算出的熵值差别很大，3500 更贴近实际。

5.2 翻车二：把aaaaaaaaaa算成强密码

现象：用户输入aaaaaaaaaa，长度 10，小写字符集 26，理论熵约 47 比特，打分 70 分以上，判定为"中等"甚至"较强"。

原因：只依赖"长度 × log₂(字符集)"的公式，完全没有考虑字符重复。公式假设每个字符独立随机，但aaaaaaaaaa显然不符合这个假设，它的实际熵几乎为 0——攻击者只要猜到"连续 10 个小写 a"这个模式，瞬间就能破解。

解决：加重复字符检测规则，对连续重复超过 3 个字符的情况直接扣 20 到 30 分。我在detect_repeated_chars里已经实现了这个逻辑，把它接入汇总打分后，aaaaaaaaaa的分数会跌到 40 分以下。同样，1111111111、!!!!!!!这类也会被规则拦住。这个规则极其简单，但能挡住大量用户"手滑"或"懒得想"的密码。

5.3 翻车三：弱口令命中没有考虑大小写和替换

现象：用户输入P@ssw0rd!，检查器显示"包含大小写、数字、符号，理论熵 50 比特，强度中等"，但它是password的简单变体，在真实攻击中几乎等于裸奔。

原因：弱口令库匹配用的是精确比较，P@ssw0rd!和库里的password对不上号。用户用小写化、加数字后缀、替换@为a等手法"变形"后的密码，直接精确匹配全部失效。

解决：匹配前先做归一化。先把密码整体小写化，再用LEET_MAP把常见数字符号替换成对应字母，最后再查弱口令库。注意替换后不要重新引入大小写，也不要做过度替换。具体操作可以看前面normalize_by_leet的实现。这里有个经验：归一化后的密码如果命中了弱口令库，扣分力度应该比普通规则重，直接扣 30 分，因为这种"变形密码"是攻击者第一个批次尝试的候选。

5.4 翻车四：反馈信息泄露导致攻击者获得更多线索

现象：检查器把所有打分细节都展示给前端，用户输入Abc@1234后，页面提示"缺少小写字母、缺少数字、熵值偏低"。攻击者拿到这些反馈，就知道系统在检查什么，可以有针对性地构造出既不触发规则又足够简单的密码。

原因：把内部判断逻辑原封不动地暴露给了不可信端。理论上，攻击者可以通过修改密码提交、观察反馈变化，反向推导出整个检查器的规则集，然后用规则集的反面来构造"刚好通过检查"的弱密码。

解决：反馈要做"降级处理"。不要返回"缺小写字母"这种具体提示，而是返回通用建议："请混合使用大小写、数字和符号，并避免常见单词组合"。弱口令命中可以说"该密码过于常见，请更换"，但不要返回"命中了第 47 条弱口令记录"。在部署时，前端只拿到分数和等级，详细扣分原因只在服务端日志里记录，这样既不影响用户体验，又不会泄露规则细节。

5.5 翻车五：性能问题——检查器被用在注册接口上

现象：检查器上线后，注册接口的 P99 延迟从 50ms 飙升到 500ms，数据库连接池被打满。排查后发现每次请求都要重新加载弱口令库并做正则匹配，CPU 全是字符串计算。

原因：弱口令库文件 1000 条记录，每次请求都读取文件、构建 Set，再加上多个正则在前端响应路径上串行执行，耗时自然不可控。更糟糕的是，正则匹配在 Python 里是 CPU 密集型操作，高并发场景下直接拖垮服务。

解决：三个优化层面。第一，弱口令库在进程启动时加载一次，放到全局变量或缓存里，不要每次请求都读文件。第二，对正则做预编译，re.compile在循环外完成，避免重复编译开销。第三，顺序优化——先做快速检查（长度、字符集统计），再做慢速检查（弱口令库、键盘序列、个人信息），如果长度不足 6 位，直接判定极弱，后面的规则一个都不用跑。实际上，多数弱密码在长度和字符集阶段就会被淘汰，最终走到正则规则环节的请求比例很低。

6. 从函数到检测服务：CLI 与 HTTP 接口的 20 行封装

到这一步，核心检测逻辑已经完整了。但真正在项目里落地，通常还需要一个统一调用入口。

# password_checker/cli.py import argparse from .checker import check_password_strength def main(): parser = argparse.ArgumentParser(description="密码强度检查工具") parser.add_argument("password", help="要检查的密码") parser.add_argument("--username", default="", help="用户名，用于检测用户信息") parser.add_argument("--json", action="store_true", help="输出 JSON 格式结果") args = parser.parse_args() result = check_password_strength(args.password, username=args.username) if args.json: import json print(json.dumps(result, ensure_ascii=False, indent=2)) else: print(f"分数: {result['score']}") print(f"等级: {result['grade']}") if result["penalties"]: print("问题:", "; ".join(result["penalties"])) if __name__ == "__main__": main()

CLI 模式主要用于本地验证和开发调试。把核心判断逻辑抽象成check_password_strength函数之后，命令行工具只是薄薄一层壳。如果你的项目要用在 Web 接口里，我推荐用标准库自带的http.server做一个小服务，不需要引入 Flask，依赖更少：

# password_checker/server.py import json from http.server import BaseHTTPRequestHandler, HTTPServer from urllib.parse import parse_qs, urlparse from .checker import check_password_strength class CheckerHandler(BaseHTTPRequestHandler): def do_POST(self): if urlparse(self.path).path != "/check": self.send_response(404) self.end_headers() return content_length = int(self.headers.get("Content-Length", 0)) body = self.rfile.read(content_length).decode("utf-8") data = parse_qs(body) password = data.get("password", [""])[0] username = data.get("username", [""])[0] result = check_password_strength(password, username=username) payload = json.dumps(result, ensure_ascii=False) self.send_response(200) self.send_header("Content-Type", "application/json; charset=utf-8") self.send_header("Content-Length", str(len(payload.encode("utf-8")))) self.end_headers() self.wfile.write(payload.encode("utf-8")) def serve(port=8080): server = HTTPServer(("127.0.0.1", port), CheckerHandler) server.serve_forever()

这里do_POST只接收表单编码数据，真正生产环境建议用 JSON 编码。但核心不在这层传输协议，而在于把检查器设计成一个无状态的纯函数，这样无论 CLI、HTTP 还是后续接入到注册流程里，调用方式都完全一致。

上线前我会固定跑一组测试样本，包括弱口令命中、键盘序列、个人信息、纯随机密码、Unicode 中文密码等十几种情况，每个样本断言分数范围和等级。这个测试用例集积累得越全，后续改打分逻辑时越有底气——毕竟这类工具最怕的不是功能缺失，而是改了规则后把原本合理的密码误杀。这套方法论我已经沿用了很久，它的价值在于：让你未来的每一次规则调优都有数据支撑，而不是靠感觉拍脑袋。

关于打分参数，我最后想多提醒一句：如果你的业务场景对账号安全有硬性合规要求，请以合规文档为准来调整阈值，不要直接照抄任何开源项目的数字。密码强度检查没有一个放之四海而皆准的公式，它是一个需要持续根据攻击方式演进的工程方向。希望这篇文章的拆解思路能帮到你，让你少走点我曾经走过的弯路。

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