企业官网建设流程全解析

前阵子我们组接到一个登录注册模块的需求，目标设备是一批基于OpenHarmony的平板和瘦客户机。团队早先的技术栈跟React体系绑得很死，ArkTS那套声明式UI语法也不是不能学，但要在两周内把注册链路和账号体系做出来，靠现学UI框架根本不现实。最后定的方案是继续用React Native写业务，跑在OpenHarmony的RN适配层上。这个决定让表单、路由、状态管理这些代码几乎原样复用，但过程中也确实踩到不少只看文档发现不了的问题。今天要聊的是这条路上一个很小但很典型的业务点——用TextInput做密码输入，再加一个实时的密码强度检测。

如果你也正面临类似处境：手上有一版RN代码库要快速移植到OpenHarmony设备，或者单纯想给现有登录表单加密码强度反馈，又不想天天求后端接口、不想引一个动不动几十K的第三方依赖，这篇文章应该能给你省点时间。下面从方案选型开始聊，逐步到评分算法、实时UI、适配层踩坑，最后给一份可以直接改的组件代码。

1. 为什么我在OpenHarmony上选了RN而不是ArkTS

在聊具体实现之前，先把这个选型问题讲清楚。因为后面所有踩坑，都跟“RN跑在OpenHarmony适配层上”这件事有直接关系。

1.1 一套代码多端复用的实际考量

如果项目是从零开始、团队人力也充足，那OpenHarmony上的最佳路径一定是官方推荐的ArkTS加ArkUI，原生性能、原生体验、官方适配都占全了。但现实往往不是这样。我们的情况是：业务层已经有一版比较成熟的RN实现，覆盖Android和iOS两个端，包含登录、注册、个人中心这些模块。而新接入的这批OpenHarmony设备，其实只需要跑其中一部分能力，拿出去给合作方做演示和试点。

这个背景下，纯ArkTS方案意味着要把登录表单、表单校验、状态管理这些代码全部用新语法重写一遍。重写之后还不算完，后续业务调整时同一个功能要同时维护两套代码。而RN方案可以做到业务逻辑和UI组件在三个端尽量复用，只有涉及原生差异的模块才需要单独适配。密码强度检测这种纯函数逻辑，在RN里写一次，三端表现完全一致，天然适合这样搞。

当然也得承认RN在OpenHarmony上的性能比不上原生ArkUI，尤其是在复杂列表和动画场景下差距会更明显。但登录注册表单这种页面，控件密度低、交互简单，RN完全扛得住。我的建议是：选型前先盘点一下目标业务是什么类型。如果只是表单、设置项、列表页这类常规界面，RN跨端复用的收益远大于性能损失；如果是大量图表绘制、复杂动画、视频处理，那就老实走ArkTS。

1.2 工程初始化与在OpenHarmony设备上跑通的最小配置

在OpenHarmony上跑RN不是直接拿官方RN仓库build就能跑的，需要依赖OpenHarmony特化的RN适配层，由开源社区维护对应分支。我们的落地步骤大致是：

1. 用RN官方脚手架创建标准工程，例如执行npx react-native init生成初始项目。
2. 按照适配层文档，在原生工程里替换入口Activity，把RN模块挂载到OpenHarmony的Ability上。
3. 用IDE工具打开原生工程，完成设备签名配置，然后连接OpenHarmony设备或模拟器运行。
4. 启动后加载JS Bundle，确认页面能正常显示再做业务开发。

这个过程里有几个容易卡住的地方。首先是版本匹配。RN核心版本和适配层版本必须严格对齐，我们在一个分支上遇到过RN版本升了一级、适配层没跟上，结果启动时直接报找不到JS Bundle的错误。其次是IDE工具的构建链版本，配置文件里的SDK版本、构建工具版本不一致时，编译期会出现各种莫名其妙的符号找不到错误，排查起来很耗时间。我的建议是，项目初始化后先把版本信息固定下来，所有组员统一环境，不要各自升级。

还有一个体验细节是，OpenHarmony设备形态混杂，从手机到平板再到一体机，屏幕宽高比差异很大。RN的布局系统在这一层跑得还算稳定，但用严格固定的dp值去做适配是行不通的，后面会具体讲。这一节先记结论：RN确实是OpenHarmony上一个可用的快速交付路线，但别把它当原生用，该绕的坑一个都不会少。

2. TextInput密码专用属性的支持程度与输入体验设计

密码输入框在RN里最核心的控件就是TextInput，但真正把它用到密码场景时，你会发现它和普通文本框还是有挺多区别的。尤其到了OpenHarmony适配层，一部分属性能用，一部分属性只是“看起来能用”。

2.1 secureTextEntry、maxLength等关键属性实测

密码输入第一个要开的就是secureTextEntry。这个属性让输入的内容以圆点形式显示，在OpenHarmony适配层上实测工作基本正常。注意我这里说的是“基本”，它和Android原生RN有一点比较明显的差异：切换该属性的瞬间光标位置不稳定，这个坑我留到第5章详细讲。

另外几个常用属性我也实际测过，整理成了一张表方便直接参考：

这张表的意义在于：在项目初期就分清哪些属性是可靠基础，哪些是“写了白写”。我们当时把textContentType写进了代码，指望它能提示系统自动填充密码，结果在适配层上完全没反应，后来才意识到这个属性根本没被映射到原生层。

2.2 密码可见性切换和数据清洗

密码输入框最常见的交互设计，就是输入框右侧放一个“小眼睛”按钮，用户点击后在密文和明文之间切换。实现上很简单：secureTextEntry绑定一个布尔状态，旁边用TouchableOpacity切换它。

const [secure, setSecure] = useState(true); <TextInput secureTextEntry={secure} // ...其他属性 /> <TouchableOpacity onPress={() => setSecure(prev => !prev)}> <Text>{secure ? '显示' : '隐藏'}</Text> </TouchableOpacity>

这里要留意的点是，切换后的光标问题会影响输入体验，尤其是密码很长或者需要定点修改时。另一个容易被忽略的是输入法状态。在密文模式下，部分OpenHarmony设备的输入法对英文和数字的联想支持不全，而且中英文切换偶尔会卡一下。我们在onChangeText里对输入值做了清洗，过滤掉空白字符，但保留了中文、emoji这类字符不过度过滤，只做提示。原因是有用户确实会在密码里放一个中文或emoji，产品上允许这种输入，那就不要在控件层强行拦截。

还有一点：密码框里要不要允许粘贴？我们的做法是允许，因为很多用户用密码管理器生成强密码，需要直接粘贴进去。但粘贴后建议立即触发一次强度检测，以免用户粘完就走、到提交时才看到一堆报错。

3. 强度评分引擎：规则权重、评分函数与提示文案映射

密码强度检测的核心不在UI，而在评估算法。这一节把评分引擎的设计思路和实现完整拆开讲。

3.1 规则评分法为什么比第三方库适合这里

密码强度检测有很多现成的npm包，大部分做得也很成熟。但为了一个密码框引入一个依赖，在OpenHarmony场景下要额外考虑这个包会不会用到不适配的能力、会不会拖慢JS引擎的加载速度。我们的选择是：不引第三方库，直接写一个规则评分函数。规则评分法的好处是透明可控，每一项权重都能按产品要求调整，而且是纯函数、离线运行、不依赖网络。

举例来说，如果产品要求“密码必须包含至少两个数字”，你只需要调整数字那一项的加分阈值。而如果依赖第三方库，这种业务规则往往得通过参数去拼凑，甚至改源码才能实现，完全不划算。密码强度检测本质上是对字符分布的统计和简单模式识别，这类计算逻辑自己写完全够用，没必要把它外包给一个黑盒。

3.2 评分函数实现：正则、逐项加分与总分归一

我们的评分维度主要有四个：长度、字符类别、特殊字符数量、明显重复或连续模式。每一项都有对应的加分或减分，最后把总分归一到0到100之间。

function containsSequence(str) { const sequences = [ 'abcdefghijklmnopqrstuvwxyz', 'qwertyuiop', 'asdfghjkl', 'zxcvbnm', '1234567890', '!@#$%^&*()', ]; const target = str.toLowerCase(); for (const seq of sequences) { for (let i = 0; i < seq.length - 2; i++) { const token = seq.slice(i, i + 3); if (target.includes(token)) { return true; } } } return false; } function evaluatePasswordStrength(password) { if (!password) { return { score: 0, level: 'weak', tips: ['请输入密码'] }; } // 用 Array.from 统计真实字符数，避免 emoji 和组合字符被 length 二次计算 const charCount = Array.from(password).length; let score = 0; const tips = []; // 长度加分，分三档 if (charCount >= 6) { score += 10; } else { tips.push('密码长度建议至少6位'); } if (charCount >= 10) { score += 10; } if (charCount >= 14) { score += 5; } // 字符类别 if (/[a-z]/.test(password)) { score += 10; } else { tips.push('可以加入小写字母'); } if (/[A-Z]/.test(password)) { score += 10; } else { tips.push('可以加入大写字母'); } if (/\d/.test(password)) { score += 10; } else { tips.push('可以加入数字'); } // 特殊字符 const symbolCount = (password.match(/[^A-Za-z0-9]/g) || []).length; if (symbolCount >= 1) { score += 15; } else { tips.push('可以加入特殊字符'); } if (symbolCount >= 3) { score += 5; } // 重复或连续模式 if (/(.)\1{2,}/.test(password)) { score -= 10; tips.push('避免连续重复字符'); } if (containsSequence(password)) { score -= 10; tips.push('避免键盘序列或字母数字序列'); } score = Math.max(0, Math.min(100, score)); let level = 'weak'; if (score >= 40) level = 'medium'; if (score >= 70) level = 'strong'; return { score, level, tips }; }

说一下几个实现细节。用Array.from(password).length而不是password.length，是因为部分设备上emoji和组合字符会被JS引擎按两个码元计算，直接统计会高估字符数，密码长度规则就被带偏了。特殊字符用/[^A-Za-z0-9]/这个正则匹配，涵盖范围比较广，中文、emoji、符号都被算作特殊字符，避免用户明明输入了特殊字符却被判定为“没有特殊字符”。连续字符检测用了一个常见键盘序列的列表，覆盖qwerty、asdf这种横向序列和12345这种数字序列。

3.3 等级划分与提示文案映射

评分函数返回的不是一个孤零零的数字，而是{ score, level, tips }三件套。level用来驱动UI颜色和指示格数，tips用来给用户具体的改进建议。

这里有个交互细节值得强调：只告诉用户“弱”“中”“强”其实帮助不大，用户更想知道的是“我该怎么改”。所以我们在tips数组里把缺失项转成具体的行动建议，比如“可以加入数字”“可以加入大写字母”。当密码为空时不显示任何强度建议，只显示中性提示；当密码非空且评分达到强等级时，不显示建议列表，直接显示等级文案。这样界面不会一开始就出现一堆红字，也不会在密码已经很强时还继续“教育”用户。

4. 实时反馈链：onChangeText、防抖、三段指示条的落地

强度评分引擎写好后，下一步是让它在用户输入时实时跑起来。这一步的难点不在评分本身，而在如何把事件触发和UI更新做得流畅自然。

4.1 onChangeText事件链路与防抖处理

最直观的做法是在onChangeText里同步执行评分函数，每次键盘敲一下就跑一次。对密码强度检测这种计算量几乎可以忽略的逻辑，直接同步跑其实也不会有什么性能问题。但真实表单里onChangeText往往不止做一件事：要更新组件状态、可能要触发错误提示、还可能要上报埋点。如果所有逻辑都塞进同一个回调里，函数会越来越臃肿，而且React Native的JS线程在低端OpenHarmony设备上本来就不宽裕，能省则省。

我的做法是给评分加一个200毫秒的防抖。用户连续输入时，上一个定时器被清掉，只有停下来超过200毫秒才真正执行评分。这个时间不是拍脑袋定的，实测下来200毫秒既能保证用户感知不到延迟，又不会在快速输入时高频触发布局重算。

const timerRef = useRef(null); const handleChangeText = useCallback((text) => { onChangeText && onChangeText(text); if (timerRef.current) { clearTimeout(timerRef.current); } timerRef.current = setTimeout(() => { setStrength(evaluatePasswordStrength(text)); }, 200); }, [onChangeText]); useEffect(() => { return () => { if (timerRef.current) { clearTimeout(timerRef.current); } }; }, []);

这里用useCallback把引用稳定下来，避免父组件每次渲染都生成新函数，导致子组件被无谓地重渲染。useEffect里的清理函数是防止组件卸载后定时器还在执行，虽然在这个小场景里不清理大概率也不会出事，但养成习惯总没坏处。

4.2 三段指示条的UI实现

强度指示条我们选了“三段填充”而不是连续的渐变色进度条。原因是三段式视觉上更清晰，用户一看就知道“现在是1格、2格还是3格”，不需要去理解百分比概念。而且三段式在OpenHarmony不同屏幕密度的设备上表现更稳定，不需要额外处理渐变渲染的性能问题。

const activeCells = strength.score >= 70 ? 3 : (strength.score >= 40 ? 2 : (strength.score > 0 ? 1 : 0)); const barColor = strength.level === 'strong' ? '#2EB872' : (strength.level === 'medium' ? '#F5A623' : '#E5484D'); <View style={styles.strengthTrack}> {[1, 2, 3].map((item) => ( <View key={item} style={[ styles.strengthCell, item <= activeCells ? { backgroundColor: barColor } : styles.strengthCellEmpty, ]} /> ))} </View>

三格指示条的逻辑很简单：强度等级为弱时点亮1格，中等点亮2格，强点亮3格，空密码时0格。每格之间留一点间距，高度控制在4个dp左右，颜色从红到橙再到绿，符合直觉。注意barColor是根据strength.level映射的，不能直接根据score算颜色，否则用户输入一个刚好40分的密码时，颜色可能会从红色跳成橙色，缺乏渐进感。

4.3 动态提示区和状态联动

指示条下面还有一个动态提示区，用来展示评分函数返回的tips或等级文案。整体交互逻辑是：密码为空时什么都不显示；密码非空且有建议时，显示最多3条建议列表；密码达到强等级时只显示“密码强度：强”。

{value ? ( strength.tips && strength.tips.length > 0 ? ( strength.tips.slice(0, 3).map((tip, index) => ( <Text key={index} style={styles.tipText}>{index + 1}. {tip}</Text> )) ) : ( <Text style={[styles.levelText, { color: barColor }]}> 密码强度：{LEVEL_TEXT[strength.level]} </Text> ) ) : null}

建议列表最多显示3条这个细节是刻意设计的。原因是当密码又短、又缺大写、又缺数字、又缺特殊字符时，提示项可能有四五个，全列出来会挤占整个表单空间，用户反而失去读下去的耐心。只显示最紧迫的3条，配合前面的指示格数，已经足够让用户明白“还差在哪”。

这段逻辑还可以和表单提交按钮联动。比如要求“只有强度达到中等以上才能提交注册”，那就在提交按钮处读取strength.level做禁用判断。但如果密码强度只是建议而非硬性要求，我建议不要禁用提交按钮，只做提示。因为有些用户场景是内网临时账号，密码策略由运维控制，产品上强行阻断反而让用户心里很急。

5. 适配层踩坑：光标、软键盘与输入法这几个老大难

RN在OpenHarmony上跑，最花时间的不是业务逻辑，而是一堆“在Android上不会出、在iOS上也不会出”的适配层问题。这一节把我们在密码输入框场景里遇到的三个主要坑完整记录下来，每个坑都附了排查思路和最终处理方式。

5.1 密文切换瞬间光标跳到末尾的根因与处理

这个坑出现的时机非常精准：输入到一半，点了右侧的“显示/隐藏”按钮，光标瞬间从当前编辑位置跳到密码末尾。第一次遇到时我以为是焦点丢失导致的，试了各种ref.focus()的组合都没有根治。

排查下来发现，问题出在原生层的处理逻辑上。RN的secureTextEntry切换本质上是给原生TextView设置变换属性并重新设置选区位置，Android原生实现里会记录当前光标位置，切换后恢复。而OpenHarmony适配层在切换后，选区回调的时机和Android不一致，导致UI层拿到的光标位置变成了末尾。

这个问题的临时处理方案是：切换时手动记录光标位置，切换后通过selection属性在下一帧强制赋值。实测在密码不超过30个字符时有效，但代价是切换瞬间输入法联想条会闪一下。我们评估后认为这个闪动比光标跳末尾的干扰更大，最终选择接受光标跳动，同时在交互上降低切换按钮出现的频率——默认密文显示，用户需要核对密码时才手动点开。这个处理方式不算完美，但属于“知道根因后的主动取舍”，比到处试奇技淫巧要省时间。

5.2 软键盘遮挡输入框：禁用KeyboardAvoidingView之后

RN里处理键盘遮挡输入框，最常见的方案是KeyboardAvoidingView，在Android上设behavior="height"，在iOS上设behavior="padding"，效果基本可靠。但到了OpenHarmony适配层，这个组件的表现时好时坏，同样是behavior="padding"，有的设备能正确顶起布局，有的设备纹丝不动，键盘直接把输入框压住了。

我们绕开了这个组件，改用了一套更朴素的方案。第一步，在原生工程清单文件里把windowSoftInputMode显式配置为adjustResize，让软键盘弹起时窗口高度被压缩。第二步，把整个登录页内容包进ScrollView，并开启keyboardShouldPersistTaps="handled"。这样键盘弹起后，输入框位于可滚动区域内，用户可以通过滑动把输入框滚到可视区域，即使不滚，因为窗口高度已被压缩，输入框往往也会被顶到键盘上方。

这套方案说不上优雅，但它在Android和OpenHarmony设备上表现一致性最好，不需要针对不同设备写条件判断。给表单页底部加一个足够大的paddingBottom，让最后一个控件即使在键盘弹起后也能通过滚动到达。

5.3 输入法在密文状态下的兼容性与输入过滤

第三个坑是输入法在密文状态下的兼容性问题。部分OpenHarmony设备自带的输入法，在secureTextEntry开启时，对英文和数字的联想支持不完整，有些设备甚至在密文模式下无法顺利切换中英文。这导致用户如果用中文输入法正在输入密码，屏幕上可能直接不响应，或者出现奇怪的组合字符。

我们能做的有两件事。第一，在密码输入框上显式设置keyboardType，注册场景用visible-password，登录场景用default。visible-password会让部分输入法直接跳过联想逻辑，减少预料之外的输入。第二，在onChangeText里对输入值做一次清洗，过滤掉空白字符，避免用户手滑输入空格导致密码校验失败。清洗时注意不要误伤中文和emoji，只用replace(/\s/g, '')就够，不要用白名单去过滤，否则很容易把用户合法的特殊字符一并删掉。

const cleaned = text.replace(/\s/g, ''); handleChangeText(cleaned);

如果产品上明确要求密码只能由字母、数字和有限特殊字符组成，那应该用白名单正则去清洗，并且要在清洗前给用户提示，而不是静默改掉。因为用户可能会困惑“我明明输了@怎么没了”，这是输入体验里很常见的一个失信细节。

6. 可直接使用的完整组件代码与调参记录

前面几章把原理和踩坑都讲完了，这一章给出一个可直接修改使用的完整组件，以及我们在实际项目里的调参记录。代码是纯JavaScript，没有额外依赖，复制进RN工程就能跑。

6.1 组件代码：从状态管理到渲染层

下面这个组件包含了密码输入框、可见性切换、强度评分、三段指示条、动态提示区，可以直接作为登录注册表单的密码输入控件使用。

import React, { useCallback, useEffect, useRef, useState } from 'react'; import { StyleSheet, Text, TextInput, TouchableOpacity, View, } from 'react-native'; const LEVEL_COLOR = { weak: '#E5484D', medium: '#F5A623', strong: '#2EB872', }; const LEVEL_TEXT = { weak: '弱', medium: '中', strong: '强', }; function containsSequence(str) { const sequences = [ 'abcdefghijklmnopqrstuvwxyz', 'qwertyuiop', 'asdfghjkl', 'zxcvbnm', '1234567890', '!@#$%^&*()', ]; const target = str.toLowerCase(); for (const seq of sequences) { for (let i = 0; i < seq.length - 2; i++) { const token = seq.slice(i, i + 3); if (target.includes(token)) { return true; } } } return false; } function evaluatePasswordStrength(password) { if (!password) { return { score: 0, level: 'weak', tips: ['请输入密码'] }; } const charCount = Array.from(password).length; let score = 0; const tips = []; if (charCount >= 6) { score += 10; } else { tips.push('密码长度建议至少6位'); } if (charCount >= 10) { score += 10; } if (charCount >= 14) { score += 5; } if (/[a-z]/.test(password)) { score += 10; } else { tips.push('可以加入小写字母'); } if (/[A-Z]/.test(password)) { score += 10; } else { tips.push('可以加入大写字母'); } if (/\d/.test(password)) { score += 10; } else { tips.push('可以加入数字'); } const symbolCount = (password.match(/[^A-Za-z0-9]/g) || []).length; if (symbolCount >= 1) { score += 15; } else { tips.push('可以加入特殊字符'); } if (symbolCount >= 3) { score += 5; } if (/(.)\1{2,}/.test(password)) { score -= 10; tips.push('避免连续重复字符'); } if (containsSequence(password)) { score -= 10; tips.push('避免键盘序列或字母数字序列'); } score = Math.max(0, Math.min(100, score)); let level = 'weak'; if (score >= 40) level = 'medium'; if (score >= 70) level = 'strong'; return { score, level, tips }; } function PasswordInputWithStrength({ value, onChangeText, placeholder, style, }) { const [secure, setSecure] = useState(true); const [strength, setStrength] = useState({ score: 0, level: 'weak', tips: ['请输入密码'], }); const timerRef = useRef(null); const handleChangeText = useCallback( (text) => { onChangeText && onChangeText(text); if (timerRef.current) { clearTimeout(timerRef.current); } timerRef.current = setTimeout(() => { setStrength(evaluatePasswordStrength(text)); }, 200); }, [onChangeText], ); useEffect(() => { return () => { if (timerRef.current) { clearTimeout(timerRef.current); } }; }, []); const activeCells = strength.score >= 70 ? 3 : strength.score >= 40 ? 2 : strength.score > 0 ? 1 : 0; const barColor = LEVEL_COLOR[strength.level]; return ( <View style={styles.container}> <View style={styles.inputRow}> <TextInput style={[styles.input, style]} value={value} onChangeText={handleChangeText} secureTextEntry={secure} placeholder={placeholder || '请输入密码'} placeholderTextColor="#9AA0A6" autoCapitalize="none" autoCorrect={false} /> <TouchableOpacity style={styles.eyeButton} onPress={() => setSecure((prev) => !prev)} accessibilityLabel={secure ? '显示密码' : '隐藏密码'} > <Text style={styles.eyeText}>{secure ? '显示' : '隐藏'}</Text> </TouchableOpacity> </View> <View style={styles.strengthTrack}> {[1, 2, 3].map((item) => ( <View key={item} style={[ styles.strengthCell, item <= activeCells ? { backgroundColor: barColor } : styles.strengthCellEmpty, ]} /> ))} </View> {value ? ( strength.tips && strength.tips.length > 0 ? ( strength.tips.slice(0, 3).map((tip, index) => ( <Text key={index} style={styles.tipText}> {index + 1}. {tip} </Text> )) ) : ( <Text style={[styles.levelText, { color: barColor }]}> 密码强度：{LEVEL_TEXT[strength.level]} </Text> ) ) : null} </View> ); } const styles = StyleSheet.create({ container: { marginBottom: 12, }, inputRow: { flexDirection: 'row', alignItems: 'center', borderWidth: 1, borderColor: '#DADCE0', borderRadius: 8, backgroundColor: '#FFF', }, input: { flex: 1, height: 44, paddingLeft: 12, paddingRight: 4, fontSize: 15, color: '#1F1F1F', }, eyeButton: { paddingHorizontal: 12, height: 44, justifyContent: 'center', }, eyeText: { color: '#3467D6', fontSize: 14, }, strengthTrack: { flexDirection: 'row', marginTop: 6, height: 4, }, strengthCell: { flex: 1, marginRight: 4, borderRadius: 2, }, strengthCellEmpty: { backgroundColor: '#E8EAED', }, tipText: { marginTop: 4, fontSize: 12, color: '#6B6F76', lineHeight: 18, }, levelText: { marginTop: 4, fontSize: 13, fontWeight: '500', }, }); export default PasswordInputWithStrength;

这个组件的接口和RN原生TextInput基本对齐，只是额外接收了onChangeText等常规属性。父组件可以直接把它当普通输入框使用，取回明文密码时读value即可，强度检测的内部状态完全是自管理的。

6.2 参数调优参考表

不同产品对“强密码”的定义不太一样。有的要求必须12位以上，有的要求必须包含特殊字符数达到2个以上，这些差异本质上是评分权重和阈值问题。我的建议是先把参数抽出来，调整时只改一个地方，不要满函数里找硬编码。

调参时要注意一个原则：评分函数的分值区间必须和UI等级完全对应。比如把“强”的阈值从70调到80，但忘了同步指示格数的判断逻辑，就会出现“分数已经很高但只亮两格”的尴尬情况。我们在代码里把等级判定统一放在评分函数里，UI层只认strength.level，不直接看分数，就是为了避免这种不一致。

6.3 后续扩展思路：从强度检测到表单联动

密码强度检测做扎实之后，有几个自然的扩展方向。最实用的是和后端密码策略联动：把评分函数做成可配置模块，由后端下发策略参数，前端动态调整权重和阈值。比如某些业务会要求“密码不能包含手机号后六位”“密码不能与用户名相同”，这类规则可以通过在evaluatePasswordStrength里追加自定义检测项实现，UI层不需要任何改动。

另一个方向是接入“确认密码”二次校验。我们在这个组件外又包了一层，在确认密码输入框里比较两次明文是否一致，不一致时直接显示错误文案。因为密码输入框本身已经自管理强度状态，确认框只需要做一个值比较，不需要重复跑一遍评分逻辑，代码量增加很少。

最后补一个个人习惯：强度检测函数我坚持写成纯函数，并且把规则、阈值、文案全部收敛在独立模块里，单元测试直接覆盖。这样后续改策略时风险可控，不会因为改了一个阈值导致其他模块跟着出问题。密码强度检测看起来是个小功能，但它同时牵涉输入控件、业务规则、UI反馈、设备适配四个层面，值得一次做扎实。