企业官网建设流程全解析

做国际化这些年，被问得最多的往往不是架构也不是性能，而是登录按钮上那三个字母到底该怎么写——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 up，in 和 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

我不敢说这是权威统计，只能说是我这些年经手和拆解过的几十个产品登录页留下的印象，仅作参考。规律大致是这样的：

这张表最实用的地方不是让你照着抄，而是让你意识到一件事：同一个产品里，面向终端用户的界面和面向开发者的文档，本来就允许用两套词。用户看到 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 的规则

这是最容易被忽略、又最容易被英语母语用户挑刺的地方。规则其实不复杂，我整理成一张表：

为什么 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 全流程文案清单：从入口到错误提示逐条对齐

这部分建议直接做成一份表交付给设计和前端，省掉来回拉扯：

第三方登录那块值得多说一句。过去大家写 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\s+On\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(encoding="utf-8", errors="ignore") 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 高频踩坑速查表

6.2 老系统迁移：显示层能改，契约层不能随便改

这是最容易出事的地方。你把界面上的 Log in 全换成 Sign in，翻译文件、设计稿、帮助文档都跟着改了，看起来很干净。但底下这些东西千万别动：URL 路径 /login、后端接口名、埋点事件名、日志里打印的动作名、已经发出去的邮件模板里的链接。

理由很直接：路径改了，用户收藏的书签失效，外部站点引用的链接 404，邮件里的老链接全部打不开。接口名改了，所有客户端版本都要同步发版，等于强制升级。埋点名改了，历史数据断成两截，报表上出现一个断崖，数据分析的人会来找你。所以要建立一条纪律：文案是显示层，可以改；标识符是契约层，改了要付出迁移成本。显示层和契约层分离，这个原则在文案规范里同样适用。

真要做迁移，走旧路径重定向到新路径，保留至少一个版本周期。埋点用双写过渡一段时间，等确认新事件跑通再下掉旧的。

6.3 我个人踩过之后总结的几条硬经验

第一条，术语表比文案本身重要。一个产品有几百条文案，靠人记是记不住的，靠一份两页的术语表就能管住。表里写清楚：登录用哪个词、注册用哪个词、退出用哪个词、错误提示统一模板、大小写规则、变量占位符格式。新来的人接手第一件事就是读这张表。

第二条，别为了“显得专业”去选生僻词。Log on 就是典型，选它的人往往觉得它更技术、更严谨，实际上它带来的是解释成本和一致性问题。用户不会因为你用了某个词而觉得你专业，只会因为点不到按钮而觉得你做得糙。

第三条，把用词决定写进决策记录。为什么选 Sign in，当时考虑了什么，谁拍的板，都留一句。半年后有人来问“为什么不用 Log in”，你翻出记录就能结束讨论。没有记录，这个讨论会重复发生五次。

第四条，先跑一遍错误路径。正常登录谁都不会写错文案，出问题的永远是“密码错三次之后的提示”“会话过期弹窗”“第三方登录回调失败”这些边角。我接手别人的项目时，第一件事就是把所有失败路径手动走一遍，通常十分钟内就能发现一堆文案不一致。

第五条，不要一次性改全站。文案调整看着没风险，实际上会牵动截图、帮助文档、培训材料、客服话术。分批改，按模块来，登录模块先动，观察一个版本周期，再推其他模块。改得太猛，最后收拾残局的时间比改的时间长得多。

最后分享一个我一直在用的小技巧：把整个登录流程的所有文案导出成一张两列的对照表，左边是英文原文，右边是你定的规范写法，逐条过一遍。这张表通常不超过三十行，半小时能过完，但它能把一个产品里 90% 的文案不一致问题一次性清掉。做完之后把它放进设计系统的文档里，下次谁要加新的登录相关文案，先来这张表里找，找不到再加。这一个动作，比开十次评审会都有用。