做国际化这些年被问得最多的往往不是架构也不是性能而是登录按钮上那三个字母到底该怎么写——Sign In、Log In 还是 Log On。这问题看着像英语语法练习实际上它牵着一整条链子品牌调性、界面文案规范、多语言本地化成本、埋点与接口命名、甚至客服知识库的关键词召回。一个按钮词选错后面所有页面都得跟着错改起来还要动设计稿、动翻译文件、动测试用例。这篇东西适合三类人看正在做产品国际化的前端和全栈、负责设计系统与文案规范的设计师、以及要拍板术语的产品负责人。我不打算给你一个“标准答案”因为这东西没有唯一解但有一套判断逻辑和一套能直接抄的落地规范看完你自己就能定并且定完不后悔。1. 三个词先拆开这不是同义词替换游戏1.1 词源决定了语感日志与签到簿是两条不同的来路Log 这个词的老家在航海。几百年前船员靠一块扇形木板系在打结的绳子上测船速那块板子叫 chip log绳子上的结就是后来速度单位 knot 的来源。船长把航速、航向、风向一笔一笔记进 logbook也就是航海日志。船員上下船、值班开始结束都要在日志里留一笔于是有了 log in 和 log out。这条来路决定了 log in 的底层语感是“留痕、记录、进入系统内部并产生一条记录”它天生带一点工程味和系统味。Sign 的来路完全不同。前台放一本签到簿你到了签个名这叫 sign in会议门口那张表叫 sign-in sheet访客登记叫 sign-in。它的语感是“我本人到场了我登记了身份”轻、日常、不涉及技术动作。所以当你在一个企业级产品里看到 Sign in它其实在强调“确认你是谁”而在一个消费级产品里看到 Log in它强调的是“进入你的账户空间继续上次的会话”。这两个来源在今天被大量混用绝大多数英语母语用户根本不会停下来分辨。但对做产品的人来说混用本身不是问题不一致才是问题。1.2 介词才是真正的分歧点in 是进入容器on 是附着于表面很多人以为三个词的区别在动词其实在介词。in 表达的是进入一个容器的内部——账户、会话、工作区都是一个有边界的空间你进去了就在里面。on 表达的是附着在某个表面上或者接通到某个网络上——on the network、on a host、on a line。所以 log on 的原始场景是调制解调器拨号、终端连主机、连上某条线路的那个年代用户真正关心的动作是“接通”。今天的云服务里“接通”这件事已经被彻底隐没在基础设施里了用户感知不到线路只感知到“我进到我的东西里面了”。当技术动作消失承载它的介词就该退场。这就是 log on 在现代消费级界面里几乎绝迹的根本原因不是它错是它描述的那个世界已经不在了。还有一个副作用值得提一句对非母语用户来说on 很容易被联想成 turn on 的“打开”于是 log on 会被理解成“把登录功能打开”歧义更大。我们在做多语言可用性测试时这类误读出现的频率不低。1.3 sign in 与 sign up 是天然一对log in 配 sign up 是不对称的这是我见过最高频的低级错误登录按钮写 Log in注册按钮写 Sign up。两个不同族的词摆在一起视觉上没问题语义上是断裂的。sign in 对 sign upin 和 up 是一组方向对立读者一眼就能建立“已有账号进 / 没有账号建”的心理映射。log in 的对立面只有 log out它没有 log up 这个说法所以一旦你用 Log in注册那边就只能被迫用 Sign up 或者 Create account配对关系被破坏。我个人的取舍标准很粗暴如果页面上同时存在登录和注册两个入口优先用 Sign in / Sign up 这一族对称性带来的认知收益远大于“log in 更技术范儿”那点调性收益。如果产品本身是开发者工具、命令行产品登录入口孤立存在、没有并列的注册按钮那 Log in 完全没问题甚至更贴调性。2. 行业惯例盘点大家到底在用什么2.1 我抽样看到的分布消费级偏 Log in企业级偏 Sign in我不敢说这是权威统计只能说是我这些年经手和拆解过的几十个产品登录页留下的印象仅作参考。规律大致是这样的产品类型更常见的用词背后的考量消费级社交、内容、电商Log in会话感强用户关心“回到我的信息流”企业协作、办公套件、B 端后台Sign in身份感强与权限、审计、组织账号绑定开发者工具、命令行、API 文档login作名词或命令与接口、配置文件、日志保持同一套词汇金融、政务、内部管理系统Sign in强调实名与身份确认老式内网系统、终端类界面Log on / logon历史遗留当年确实是“接通线路”这张表最实用的地方不是让你照着抄而是让你意识到一件事同一个产品里面向终端用户的界面和面向开发者的文档本来就允许用两套词。用户看到 Sign in开发者文档里写 login API这不叫不一致这叫面向不同读者的分层表达。真正的不一致是同一个页面上登录叫 Sign in、退出叫 Log out。2.2 我不推荐 Log on 的五个理由第一空间隐喻已经失效前面说过它描述的是接通线路而今天的用户根本没有这个心智模型。第二它没有稳定的名词形态logon、log-on、log on 三种拼法在旧文档里全都能找到做术语库的时候非常难受。第三它和 log in 混用会制造同义词噪音客服知识库、站内搜索、帮助中心的关键词召回都要多维护一套。第四它在某些语境里会被误读成“打开登录功能”非母语用户尤其容易踩。第五也是最现实的现代设计系统里几乎找不到以 log on 为主用词的成功范例可以对照你选它就是在给自己增加解释成本。Sign on 的情况类似但更微妙。它在人力、金融语境里有“签约加入”的含义比如入职奖金这类词就用 sign-on语感是“正式加入某个组织”。所以如果你的产品是招聘、员工入职、会员签约类场景Sign on 反而可能有它的位置。但用在普通的账号登录上它同样显得年代感过重。2.3 名词形态的三种写法login、log in、log-in 的规则这是最容易被忽略、又最容易被英语母语用户挑刺的地方。规则其实不复杂我整理成一张表形态词性正确写法例子动词短语动词分开写两个词Pleaselog into continue.名词名词连写成一个词Go to theloginpage.形容词定语连写成一个词Enter yourlogincredentials.sign 的动词短语动词分开写Sign inwith your work account.sign 的名词名词加连字符Fill out thesign-inform.为什么 log 能连写而 sign 要连字符因为 log 本身是名词性词根名词加副词直接合成复合名词英语里很自然sign 是动词动词加副词要变成名词中间不加连字符会读成一个怪词signin所以规范写法是 sign-in。这也是为什么你在正经产品的文案里几乎看不到 signin 这个拼法但 login 连写非常普遍。3. 一套能直接抄的登录系统英文文案规范3.1 先定“族”再定“词”两套风格任选其一禁止混搭我的建议是先把整个产品的文案归入两族之一然后全站执行中途不改。A 族Sign 系Sign in / Sign up / Sign out。B 族Log 系Log in / Create account / Log out。两族都能用选哪族看产品气质。B 族的短板是没有 log up注册那边得另找一个词最稳的是 Create account它比 Sign up 更明确也避开了“注册到底是建账号还是订阅”的歧义。A 族的短板是在开发者语境里略显“商务”但对绝大多数终端用户毫无障碍。真正要严禁的是混搭。我看到过最离谱的一个页面标题写 Welcome back按钮写 Log in下面一行小字写 Sign in to continue退出按钮写 Sign Out。用户可能不会抱怨但这是典型的团队没有术语纪律。3.2 全流程文案清单从入口到错误提示逐条对齐这部分建议直接做成一份表交付给设计和前端省掉来回拉扯位置A 族推荐B 族推荐备注页面标题Sign inLog in与按钮同词不要标题一个词按钮另一个词主按钮Sign inLog in动词短语句首大写即可注册入口Sign upCreate account与登录入口并列时视觉权重区分开第三方登录Continue with {provider}Continue with {provider}现代产品更常用绕开“登录还是注册”的纠结记住我Keep me signed inKeep me logged in比 Remember me 明确说明了效果忘记密码Forgot your password?Forgot your password?带 your 更自然问号不能省已登录状态Youre signed in as {email}Youre logged in as {email}用被动/系表结构不要用进行时会话过期Your session has expired. Please sign in again.同左换 log in告诉用户发生了什么再给动作退出Sign outLog out必须与登录同族这是最容易出错的地方凭据错误Incorrect email or password.同左不要指明是哪个错了第三方登录那块值得多说一句。过去大家写 Sign in with {provider}现在越来越多产品改成 Continue with {provider}。原因很实在用户看到 Sign in with 会犹豫“我是要登录还是要注册”而 Continue with 把这两个动作合并了点了继续往下走系统自己判断是新用户还是老用户。这个小改动在很多产品上带来的注册转化提升是实打实的因为它消除了一次决策。3.3 大小写、标点与语气三个细节决定专业度大小写方面现代设计系统基本都转向 sentence case也就是只有首字母大写Sign in 而不是 Sign In。Title Case 在按钮上会显得老派而且在多语言环境里很难定规则哪些词算实词冠词介词要不要大写翻译团队每次都要问一遍。统一 sentence case规则一句话讲清楚省事。标点方面按钮文案不加句号这一条几乎没有例外。错误提示要加句号因为它是一句完整的话。Forgot your password? 的问号必须保留它提示用户“这里可以点”。省略号只在表示“还需要下一步”时使用比如 Continue… 这种但按钮上我更倾向不用容易显得犹豫。语气方面错误提示最考验功力。Invalid credentials 太技术Login failed 太冰冷Incorrect email or password 是目前的公认写法。另外安全上不要回显用户输入的账号也不要说“该账号不存在”——那等于给攻击者做账号枚举的免费接口。统一一句“邮箱或密码不正确”谁都不得罪。4. 本地化会把问题放大三倍4.1 中文“登录”的对应关系以及东亚语言的音译红利中文的“登录”其实更贴 log in 的语义因为它带一点“登记在册”的意味。但中文用户在界面上看到“登录”脑子里不会区分 sign 还是 log所以这个词的选择对中文版毫无影响。真正的差异出现在你要做多语言的时候。日语和韩语里登录这个词基本是以 log in 为词源的外来语音译写法稳定、认知统一。这意味着如果你的产品要出这两个语言版本B 族Log 系在术语一致性上成本更低翻译团队不用纠结“sign 该译成什么”。而 A 族在某些语言里会撞上一个尴尬表示“签到/登记”的动词在那些语言的日常用法里更接近“报名参加活动”用在软件登录上会有一点点错位感。反过来某些欧洲语言里表示“登记、报名”的动词反而成了主流因为它和当地的行政、教育语境高度绑定。这时候 A 族的语义反而更顺。结论是术语选型不能只看英语要拿日语、韩语、德语、法语这几个关键语种先做一轮词库预演看哪个族的翻译链路更短、歧义更少再反推英语用哪个。4.2 伪本地化测试按钮宽度是被低估的战场英语 Log in 六个字符换成某些语言可能翻一倍还多。登录按钮通常是页面视觉重心宽度一变整个表单的布局就得重排。我习惯在开发早期就跑一轮伪本地化把所有文案统一加长 30% 到 40%把字母替换成带变音符号的字符看看按钮会不会溢出、会不会换行、会不会把旁边的“忘记密码”挤掉。具体做法不难。前端把语言包里的字符串做一层转换在字符前后插入占位符把关键字母替换成 ẞ、é、ü、ñ 这类宽度更大的字符然后拿这个伪语言包跑一遍全流程。登录页尤其要看三个地方主按钮、错误提示条、以及“记住我”那一行的复选框对齐。错误提示最容易翻车因为它的长度在正常状态下没人测。还有从右到左书写的语言整个表单的视觉流向要镜像输入框里的邮箱地址却必须保持从左到右。这种混合方向的处理不做测试根本发现不了上线后才被用户投诉。4.3 占位符、复数与动态内容的安全边界文案里一旦出现变量事情就复杂了。欢迎语 Welcome back, {name} 里的名字可能是任何字符长度不可控某些语言里名字要加敬称或者变格。时间类的文案更麻烦Last sign-in: {time} 在有的语言里需要根据时间远近换动词形态如果当初只准备了一个模板翻译只能硬译。安全边界也要在这里划清楚。错误提示、欢迎语、账号信息这类文案不要把用户输入原样回填进页面尤其是错误提示一旦回显就可能被用来做注入或者做账号确认。变量传进模板之前做一次转义这是基本功但在文案层经常被“反正只是显示”这种心态绕过。5. 工程侧怎么把规范固化成不会再犯的机制5.1 i18n key 的命名别拿英文原文当 key最省事的做法是把英文原文直接当 key短期爽长期是灾难。你哪天把 Log in 改成 Sign in所有引用这个 key 的地方全要跟着改翻译记忆库也会跟着错乱。正确做法是用语义化的 key{ auth.signin.title: Sign in, auth.signin.action: Sign in, auth.signin.remember: Keep me signed in, auth.signout.action: Sign out, auth.signup.action: Sign up, auth.error.credentials: Incorrect email or password. }命名空间用 auth 开头动作和文案分层改文案不改 key。这套结构还有一个好处你能一条命令查出所有登录相关文案做一致性核对非常快。5.2 用脚本守住一致性三行命令查全站用词人工 review 靠不住得让机器盯着。第一步先看文案文件里有没有混族jq -r keys[] locales/en.json | grep -Ei sign_?in|log_?in|sign_?out|log_?out如果输出里 signin 系和 login 系同时出现八成有人在混搭去查具体哪条。第二步扫源码里的硬编码防止有人绕过语言包直接写死文案import re from pathlib import Path # 粗筛源代码里直接出现的登录类文案 PATTERNS [ (log_on, re.compile(r\bLog\sOn\b, re.I)), (signin_oneword, re.compile(r\bsignin\b(?!\s*), re.I)), (login_button, re.compile(r\blogin\b(?!\s*[:]), re.I)), ] for p in Path(src).rglob(*): if p.suffix not in (.tsx, .jsx, .vue, .html): continue text p.read_text(encodingutf-8, errorsignore) for name, pat in PATTERNS: for m in pat.finditer(text): line text[:m.start()].count(\n) 1 print(f{p}:{line} [{name}] {m.group(0)})这段脚本肯定有误报比如变量名也叫 login、接口路径也叫 login这很正常。它的价值是缩小人工检查的范围从“通读几千行”变成“看十几个命中点”。我习惯把它塞进 CI 的 lint 阶段允许 warning 不允许 error先跑一个月看噪音量稳了再升级成阻断。5.3 A/B 测试与可访问性别只盯着点击率如果非要测 Sign in 和 Log in 哪个转化高先想清楚测什么指标。只测按钮点击率是没有意义的因为两个词指向同一个动作点击率的差异大概率是噪音。真正值得看的是登录成功率和登录后 24 小时内的留存前者反映用户有没有被文案误导后者反映这次会话的质量。样本量要提前算。两个版本的差异如果只有零点几个百分点你需要几十万的样本才能达到统计显著大多数产品的登录页根本撑不起这个量级。所以我的一般态度是这类文案差异不值得做 A/B值得做的是可用性测试。找五到八个目标用户让他们完成“退出后重新登录”这个任务看有没有人卡住、有没有人点错到注册页。五个人的定性反馈比二十万次曝光的数据更有解释力。可访问性这块是硬要求。按钮文案必须能被屏幕阅读器读成一个动词短语Log in 会被朗读为动词而单独的 Login 有可能被读成名词甚至词不达意。不要只放图标不放文字如果因为空间限制必须只放图标那就得补 aria-label写清楚动作而不是写“button”。登录失败的提示要让屏幕阅读器主动播报别做一个视觉上的红色小字就完事。6. 常见问题与排查实录6.1 高频踩坑速查表现象常见原因处理方式登录和退出用词不同族不同人分批写的文案全站统一到一族退出必须跟登录注册入口和登录入口不对称用了 Log in 却没有 Log up换 Create account或整族改 Sign名词当动词用代码里出现 Please login to continue动词必须分开写 log in按钮文案溢出未做伪本地化加 30%~40% 长度冗余再排布局错误提示泄露账号是否存在按不同情况给了不同提示统一成一句“邮箱或密码不正确”屏幕阅读器读不明白只放图标或用名词做按钮补 aria-label写明动作改了文案但埋点全乱埋点事件名跟着文案改事件名与显示文案解耦客服搜不到帮助文档站内和文档用了不同术语术语库对齐检索同义词兜底6.2 老系统迁移显示层能改契约层不能随便改这是最容易出事的地方。你把界面上的 Log in 全换成 Sign in翻译文件、设计稿、帮助文档都跟着改了看起来很干净。但底下这些东西千万别动URL 路径 /login、后端接口名、埋点事件名、日志里打印的动作名、已经发出去的邮件模板里的链接。理由很直接路径改了用户收藏的书签失效外部站点引用的链接 404邮件里的老链接全部打不开。接口名改了所有客户端版本都要同步发版等于强制升级。埋点名改了历史数据断成两截报表上出现一个断崖数据分析的人会来找你。所以要建立一条纪律文案是显示层可以改标识符是契约层改了要付出迁移成本。显示层和契约层分离这个原则在文案规范里同样适用。真要做迁移走旧路径重定向到新路径保留至少一个版本周期。埋点用双写过渡一段时间等确认新事件跑通再下掉旧的。6.3 我个人踩过之后总结的几条硬经验第一条术语表比文案本身重要。一个产品有几百条文案靠人记是记不住的靠一份两页的术语表就能管住。表里写清楚登录用哪个词、注册用哪个词、退出用哪个词、错误提示统一模板、大小写规则、变量占位符格式。新来的人接手第一件事就是读这张表。第二条别为了“显得专业”去选生僻词。Log on 就是典型选它的人往往觉得它更技术、更严谨实际上它带来的是解释成本和一致性问题。用户不会因为你用了某个词而觉得你专业只会因为点不到按钮而觉得你做得糙。第三条把用词决定写进决策记录。为什么选 Sign in当时考虑了什么谁拍的板都留一句。半年后有人来问“为什么不用 Log in”你翻出记录就能结束讨论。没有记录这个讨论会重复发生五次。第四条先跑一遍错误路径。正常登录谁都不会写错文案出问题的永远是“密码错三次之后的提示”“会话过期弹窗”“第三方登录回调失败”这些边角。我接手别人的项目时第一件事就是把所有失败路径手动走一遍通常十分钟内就能发现一堆文案不一致。第五条不要一次性改全站。文案调整看着没风险实际上会牵动截图、帮助文档、培训材料、客服话术。分批改按模块来登录模块先动观察一个版本周期再推其他模块。改得太猛最后收拾残局的时间比改的时间长得多。最后分享一个我一直在用的小技巧把整个登录流程的所有文案导出成一张两列的对照表左边是英文原文右边是你定的规范写法逐条过一遍。这张表通常不超过三十行半小时能过完但它能把一个产品里 90% 的文案不一致问题一次性清掉。做完之后把它放进设计系统的文档里下次谁要加新的登录相关文案先来这张表里找找不到再加。这一个动作比开十次评审会都有用。