1.1 明确简单AI翻译网页的功能边界与使用场景
我最初想做这个翻译网页，纯粹是因为自己看外文资料时总在多个工具之间来回切换，烦得很。一个简单AI翻译网页，在我脑子里就是打开浏览器输入网址，粘贴一段文字，选一下语言，点个按钮，译文马上出来。功能边界得卡死：只处理纯文本翻译，不做文档上传、不做语音识别、不做图片OCR。这样做的好处是开发周期短，维护成本低，用户也不用注册登录。使用场景其实挺具体的——比如读英文技术博客时遇到生词段落，或者收到一封外语邮件想快速看懂大意，又或者写东西时临时需要把中文句子转成英文。这些场景下，用户要的是“快”和“直接”，不是功能大而全。
从用户角度琢磨，我发现很多人用翻译工具时最怕两件事：一是等半天没反应，二是界面复杂找不到输入框。所以我给自己定的目标很明确：页面打开就能看到输入区域，语言选择用下拉菜单，翻译按钮足够大。不搞历史记录、不搞收藏夹、不搞账号体系。我甚至想过要不要加个“复制译文”按钮，后来觉得浏览器自带选中复制就够了，先不加。这种克制让项目边界清晰，也让我在后续写API调用教程时能聚焦在核心流程上，而不是被各种边缘功能带偏。
换个角度从开发者的视角看，明确功能边界等于给自己画了一条护城河。我见过太多小项目一开始想法很丰满，做着做着就加需求，最后烂尾。简单AI翻译网页的核心价值就是“轻量”，用户不需要学习成本。我在笔记里写下一句话：任何让用户多点击一次的设计都要重新考虑。这句话后来贯穿了整个开发过程。使用场景里还有一个隐含需求——移动端访问。很多人是在手机上临时查翻译，所以页面必须能自适应小屏幕，这一点在功能边界阶段就得记下来，不能等写完PC端再补。
1.2 选择翻译API并了解调用限制与费用规则
翻译API的选择直接决定了项目能不能低成本跑起来。我花了一个下午对比了几家主流服务：Google Cloud Translation、DeepL API、百度翻译开放平台、腾讯云机器翻译、阿里云翻译。说实话，大厂的API质量都不差，差别主要在免费额度和调用限制上。Google和DeepL对个人开发者有免费层，但需要绑定信用卡，我有点犯怵。百度翻译和腾讯云在国内访问速度快，免费额度对一个小网页来说够用。我最后选了一个有每月免费字符额度的API，具体名字这里不提，免得像广告。关键是你在选的时候要盯着三个数字：免费调用次数、每次请求的字符上限、超出后的单价。
调用限制这块我踩过一个小坑。有些API的免费额度是按“字符数”算的，不是按“请求次数”。一个请求里塞5000个字符和塞50个字符，消耗的额度差很多。我在教程里会提醒读者，每次翻译前先估算输入长度，超过单次限制就得分段。费用规则也要看清楚，有的API免费额度用完后自动按量计费，如果你不设预算提醒，月底账单可能吓你一跳。我给自己定的策略是：只使用免费额度内的调用，在代码里加一个简单的计数器，超过阈值就提示用户“今日免费额度已用完”。这个思路写进教程里挺实用，读者照着做不会花冤枉钱。
还有一个容易被忽略的点：API的响应格式和错误码。不同服务商返回的JSON结构不一样，有的把译文放在data.translations[0].text，有的放在translated_text。我在选型阶段就下载了每个API的示例响应，对比着看哪个解析起来最顺手。另外要了解限流规则，比如每秒最多几次请求。简单网页通常不会触发限流，但如果你在教程里教别人批量翻译，这个信息就很重要。我建议在项目准备阶段就把这些规则整理成一张小卡片，贴在代码注释里，后面写调用逻辑时随时对照，省得反复翻文档。
1.3 准备开发环境与基础项目文件结构
我的开发环境特别朴素：一台普通笔记本，装着VS Code和Chrome浏览器。没有用Webpack、Vite这些构建工具，也没有上框架。为什么？因为这是一个“简单AI翻译网页”，引入构建工具反而增加学习门槛。我新建了一个文件夹，里面放三个文件：index.html、style.css、script.js。后来觉得API密钥直接写在script.js里不安全，又加了一个config.example.js作为示例，真正的config.js加到.gitignore里。这个结构对新手友好，打开文件夹就能开始写代码，不需要理解模块打包的概念。
本地测试我用的是VS Code的Live Server插件，点一下就能在浏览器里预览，改完代码自动刷新。如果你不想装插件，直接用浏览器打开HTML文件也能跑，只是fetch请求可能会遇到跨域问题（这个后面章节会处理）。我还在项目根目录放了一个README.md，里面写清楚项目用途、如何替换API密钥、如何本地运行。说实话，写README花的时间比想象中多，但它对教程读者很有帮助——别人拿到你的代码，第一眼看到的是说明文档，不是一堆陌生文件。文件结构保持扁平化，不要建src/、dist/这些深层目录，简单项目就要有简单项目的样子。
从协作角度看，我习惯在项目开始前先建一个docs/文件夹，把API文档截图、费用说明、调用限制这些零散信息丢进去。这个习惯来自以前做项目时到处找文档的痛苦经历。简单网页虽然小，但准备阶段多花十分钟整理环境，后面写代码能省两小时。我还试过用Node.js起一个本地服务器，后来发现Live Server足够用，就放弃了。开发环境的选择原则是：能用现成工具解决的，绝不自己造轮子。这句话我也会写进教程的开头，提醒读者别在环境配置上过度纠结。
1.4 梳理AI翻译网页API调用教程的核心流程
写教程和写代码是两码事。我在动手写第一行代码之前，先拿了一张白纸，把用户从打开网页到看到译文的完整路径画了出来。核心流程其实就五步：用户输入文本、选择源语言和目标语言、点击翻译按钮、JavaScript读取输入并构建API请求、收到响应后渲染译文。这五步里每一步都有细节可以展开，但教程不能一上来就堆细节。我的思路是先让读者跑通一个“最小可用版本”，再回头讲错误处理和加载状态。最小版本里，语言选择可以只支持中英互译，输入框加一个按钮，fetch请求写死参数。跑通之后，读者会有成就感，再往下学复杂逻辑就不容易放弃。
API调用教程的核心流程里，我特别看重“请求构建”这一步。很多新手卡在不知道怎么把用户输入拼进URL或者请求体。我的做法是在教程里直接给出一个fetch的代码片段，把API地址、密钥、文本参数、语言参数都标清楚，然后逐行解释每个参数从哪来。比如源语言参数来自下拉菜单的value，目标语言同理，文本参数来自输入框的value。这样读者能建立“页面元素→JavaScript变量→API参数”的映射关系。另外我会强调一次完整的请求包含四个部分：请求地址、请求方法、请求头、请求体（或查询参数）。不同API的请求方法可能是GET或POST，教程里要明确标注。
还有一个流程上的细节：响应处理。API返回的JSON里，译文的位置可能藏得很深。我建议读者先在浏览器开发者工具的Network面板里看一眼原始响应，再写解析代码。教程里我会放一张示意图（文字描述版），展示从response.json()到最终文本的路径。错误处理放在核心流程的最后讲，但代码里要留好try...catch的骨架。这样读者第一遍跑通正常流程，第二遍加上错误处理，循序渐进。整个教程的节奏我预想是：先讲清流程，再给代码，最后解释为什么这么写。这种“先见森林后见树木”的写法，对初学者比较友好。
2.1 简单AI翻译网页HTML代码示例与页面结构搭建
我写HTML的时候有个习惯，先不急着敲代码，而是拿张纸画个草图。简单AI翻译网页的布局其实特别直观：顶部放标题，中间是输入区，下面是大按钮，再往下是结果展示区。草图画完我扫了一眼，觉得这页面要是再复杂就多余了。HTML结构就按这个顺序来，一个<header>放标题，一个<main>包住所有交互区域，<main>里面分三块——输入框块、语言选择块、结果输出块。每一块用<section>隔开，不是为了多写标签，是方便后面加CSS的时候能按块定位。
我手头留着一个最简版本的结构示例，大概长这样：一个textarea用来输入原文，两个select分别管源语言和目标语言，一个button负责触发翻译，底下跟一个div放译文。这里有个细节我得提一下，textarea的初始值我设成了空字符串，没放占位提示“请输入要翻译的文字”，因为浏览器自带的placeholder属性就够用了，没必要用JS去控制初始内容。语言下拉菜单的选项我也没写死一堆，先放了中英日韩四个常用项，后面想扩再加。按钮的文字就三个字“翻译一下”，比“开始翻译”短一个字符，但在手机上显示更自然。
页面结构搭建这块，我犯过一个新手错误：一开始把<script>标签放到了<head>里，结果JS跑的时候页面上按钮还没渲染出来，拿不到DOM节点。调了半天才反应过来，把<script>挪到</body>前面就没事了。后来学乖了，直接在<script>标签上加defer属性，既能保持代码在HTML里靠前的位置，又不会阻塞页面渲染。这个坑我在教程里专门标了一笔，读者照着抄代码的时候不会踩同样的雷。
我还试过给页面加一个<form>标签把输入区包起来，想着万一以后要支持回车提交。后来发现<form>默认提交会刷新页面，得加preventDefault()，多一步操作就多一个出错点。果断把<form>拿掉，换成普通的<div>。简单网页就该用最简单的标签，语义化这东西在个人项目里得给效率让路。<main>和<section>我留着是因为它们不影响布局，纯粹给代码阅读加点层次感。
2.2 输入框、语言选择与翻译按钮的交互设计
交互设计这块，我脑子里的画面特别清晰——用户打开页面，光标自动落在输入框里，直接开始打字，选完语言点按钮，完事。为了做到“光标自动落下”，我在JS里加了一行document.getElementById('inputText').focus()，页面加载完自动聚焦。这个细节不起眼，但实际用起来差别挺大，省了用户一次点击，尤其手机上不需要再去戳一下输入框。输入框的高度我设了rows="6"，能显示大概五六行文字，不至于让用户觉得“这地方太小了塞不下”。
语言选择用原生<select>，没上自定义下拉组件。原因很简单，原生控件在手机上会调起系统选择器，操作体验比自绘的顺滑多了。我见过一些教程教读者用<div>模拟下拉菜单，还要处理点击外部关闭、键盘导航这些事，代码量翻倍，效果还不一定好。简单项目就选简单方案，原生<select>改不了太多样式，但能正常工作比好看重要。源语言下拉菜单里我加了一个“自动检测”选项，value设成空字符串，这样用户不选源语言也能翻译，API那边一般会自己判断。
翻译按钮的设计我纠结了一阵。一开始想做成大圆角加渐变色，后来对着屏幕看了半天，觉得太花哨了，跟工具类网页的调性不搭。最后改成了方块造型，背景色用了一个中性的深蓝，文字白色，圆角只给4个像素。按钮宽度设了100%，手机上手指好点。我还在按钮上绑了一个click事件监听，没用onclick属性，原因是事件监听可以挂多个函数，后面加加载状态的时候不用回头改HTML。这个习惯是从实际项目里养成的，HTML里少写逻辑，JS文件里集中管理行为，维护起来清楚得多。
有一个交互细节我做了删减。最开始我想加一个“交换语言”的小按钮，中英互译时一键对调源语言和目标语言。画原型的时候觉得挺方便，后来想了想，用户多一步操作去点这个按钮，跟直接在下拉菜单里重新选一次，效率上没本质区别，还多占一块屏幕空间。删掉。交互设计的原则我总结成一句话——能用默认行为解决的，不增加自定义按钮。输入框支持Ctrl+Enter快捷键触发翻译这事我也考虑过，纠结了五分钟还是放弃了，原因是得在教程里多解释一段键盘事件监听，对新手来说超出核心流程范围了。
2.3 使用JavaScript调用翻译API并渲染翻译结果
写JS调用API这段代码的时候，我先把思路捋了一遍：拿到输入框里的文字，拿到两个下拉菜单当前选中的语言代码，拼一个请求对象，发出去，等回来，把译文塞进结果区域。就这么四步。代码里我用的是fetch，没用XMLHttpRequest，原因没别的，fetch写起来短，基于Promise的写法也比回调函数好读。请求方法我用的是POST，API文档里写的，参数放在请求体里，headers里标明Content-Type: application/json。密钥我放在一个单独的config.js文件里，通过<script>标签引入，这样script.js里只写API_KEY这个变量名，具体值不暴露在主要代码文件里。
请求体里的参数我一行一行对着API文档抄。源语言参数的值来自sourceLangSelect.value，目标语言参数的值来自targetLangSelect.value，待翻译文本来自inputText.value。这里有个小技巧，我用encodeURIComponent处理了一下输入文本吗？其实POST请求体里直接放JSON字符串就行，不需要手动编码。但我在教程里特意提醒读者，如果你选的API要求GET请求，文本参数必须做URL编码，不然特殊字符会把请求地址搞坏。我自己用的这个API支持POST，省了这一步，但教程里得说清楚两种情况。
渲染翻译结果的时候，我最初是把API返回的整个JSON对象console.log出来，在开发者工具里一层一层展开找译文。找了两三次之后，我直接把解析路径写死在代码里：data.translations[0].translatedText（这是我用的那个API的结构，你用的可能不一样，去Network面板里看一眼原始响应就知道了）。拿到文本后，用一个resultDiv.innerText塞进去。为什么用innerText不用innerHTML？因为innerHTML会把译文里的HTML标签也渲染出来，万一API返回的内容带尖括号，页面就乱套了。innerText只认纯文本，安全省心。这个选择我写进教程里了，顺带提了一句XSS攻击的基础概念，不用展开，让读者有个意识就行。
代码组织上我做了一个小优化，把“发请求”和“解析响应”拆成了两个函数。translateText()负责构建请求、发fetch、处理错误，renderResult()只负责把拿到的字符串放到页面上。拆开的好处是后面加加载状态的时候，我只改translateText的调用处，renderResult完全不用动。函数名我起得特别直白，没用什么handleTranslateClick这种长名字，就doTranslate，读起来顺口。注释我写得比较密，几乎每行关键代码上面都有一句中文说明，毕竟教程读者可能对fetch和async/await不熟。
2.4 加载状态、错误提示与输入校验处理
加载状态是我第一个加的辅助功能。原因很直接，我本地测试的时候点了翻译按钮，网络稍微慢一点，页面两三秒没反应，我自己都忍不住想再点一次。用户肯定也一样。我的处理办法是按钮点击后立刻把按钮文字改成“翻译中…”，同时给按钮加一个disabled属性，防止重复提交。等fetch的Promise resolve或者reject之后，再把按钮文字恢复成“翻译一下”，移除disabled。这个逻辑我用try...finally包住了，finally里恢复按钮状态，这样不管请求成功还是失败，按钮都不会卡在“翻译中”。
错误提示我分了三种情况。第一种是输入框为空，用户没打字就点翻译，我直接alert('先输入点内容吧')，简单粗暴但有效。第二种是网络错误或者API返回非200状态码，我在结果区域显示一行红字“翻译失败了，检查一下网络或者API密钥”。第三种是API返回了200但响应体里的结构不对，比如没有译文字段，这种情况我也给了一个统一的提示“返回结果格式看不懂，去控制台看日志”。三种错误对应三种处理方式，代码里用if...else分了一下。说实话，alert弹窗体验一般，但胜在代码量少，读者一眼就能看懂。教程里我提了一句，进阶读者可以换成页面内的提示条，视觉上更舒服。
输入校验方面我做了两件事。一是检查输入文本长度，超过API单次请求的字符上限就截断，并在结果区域提示“太长了，只翻译了前XXX个字”。API文档里写的是单次最多5000字符，我在代码里设了一个4000的软限制，留点余量。二是检查输入是否全是空白字符，用trim()判断一下，空白输入直接拦掉。语言选择我没做校验，源语言选了“自动检测”也没关系，API自己能处理。这里有个小细节，用户快速连点翻译按钮的时候，虽然按钮有disabled属性挡着，但保险起见我还是在函数开头加了一个isLoading变量判断，双重保险。
我印象很深的一次调试，API密钥写错了，fetch返回401，但我代码里只判断了response.ok是false就弹“网络错误”，找了好半天才发现是密钥的问题。后来我把错误处理改细了，先判断response.status，401和403专门提示“检查API密钥”，429提示“请求太频繁”，其他再走通用错误。这个改动花了我二十分钟，但对读者来说价值很大——他们照着教程做，遇到报错能直接定位问题方向，不用像我一样瞎猜。
2.5 基础样式设计与移动端适配
样式这块我没什么艺术细胞，所以走了极简路线。整个页面就一个主色调，深蓝配白底，文字用深灰色，输入框和按钮之间留了20像素的间距。字体用的是系统默认字体栈system-ui, -apple-system, sans-serif，没引入任何外部字体文件，加载速度快，看着也不丑。输入框加了1像素的浅灰边框，圆角4像素，聚焦的时候边框变蓝——就这一个视觉反馈，够了。结果区域用了一个浅灰背景的盒子，跟输入框区分开，用户一眼能看出哪块是输出。
颜色和字号我调了两轮。第一轮字号全设了16像素，在电脑上看着正常，手机上输入框里的字显得太大，一行没几个字就换行了。第二轮我把输入框字号降到15像素，按钮文字16像素，结果区域15像素。这个调整幅度很小，但实际观感差别不小。行高我设了1.6，段落读起来不挤。按钮的padding上下给了12像素，手指点上去不容易误触旁边的元素。这些数字没什么依据，纯粹是我对着浏览器开发者工具来回拖动调出来的，调到自己看着顺眼为止。
移动端适配我用的是最简单的办法——加一个<meta name="viewport" content="width=device-width, initial-scale=1.0">，然后所有宽度用百分比或者max-width控制。主容器设了max-width: 640px，margin: 0 auto居中，电脑上不会拉成一条长线，手机上自动撑满屏幕。输入框宽度100%，按钮宽度100%，语言选择两个<select>并排放，各占45%宽度，中间留10%空隙。这个布局在360像素宽的小屏上也不会挤。媒体查询我只写了一个断点，max-width: 480px的时候把两个下拉菜单改成上下排列，因为有些小手机上并排显示两个下拉菜单，文字会被截断。
测试移动端适配的时候，我用Chrome开发者工具的设备模拟功能来回切换了iPhone SE、iPhone 14和一台安卓机的尺寸。发现了一个小问题：在iPhone SE这种小屏幕上，页面底部的结果区域离屏幕边缘太近，手指滑动的时候容易误碰。解决办法是在<main>容器上加了一个左右10像素的内边距。改完之后再切到模拟器上看，舒服多了。整个样式文件一共不到八十行，没有用任何CSS框架，没有预处理器，改哪个颜色直接打开style.css搜十六进制色值就行。简单项目的样式就该这么朴素，维护成本几乎为零。
3.1 功能测试与常见问题排查
做完了页面和翻译功能，我差点直接截图发朋友圈说“大功告成”。还好忍住了，随手点了几下按钮，发现输入英文翻译成中文时，结果区域偶尔会空着不显示内容。打开控制台一看，API返回的JSON里多了一层嵌套，跟我之前写死的解析路径对不上。那次经历让我老老实实列了张测试清单，把常用的中英日韩四种语言两两组合都跑了一遍，加上长文本、带标点的句子、纯数字、emoji表情这几类输入。手动测试花了不到半小时，找出来的问题比我拍脑袋想的多了三倍。你照着做的时候也可以这么干，拿张纸把语言对画成表格，跑一个勾一个，比漫无目的地乱点靠谱。
常见的坑我踩过好几个，印象最深的是CORS跨域报错。本地用file://协议打开HTML文件，fetch请求直接被浏览器拦下来，控制台一片红字。换成用VS Code的Live Server插件起一个本地服务器，问题就没了。这个坑我在教程里用加粗字体标了出来，新手很容易卡在这。另一个高频问题是API返回401，我前面提过密钥写错的情况。还有一次是请求体里的参数名拼错了，API不报错，直接返回原始文本当译文，看起来像是没翻译，查了半天才发现是参数名少了个字母。这种“静默失败”最烦人，测试的时候盯紧返回的JSON原始内容，别光看页面上渲染出来的文字。
排查问题我养成了一个固定动作：不管什么错，先按F12打开Network面板，找到那个翻译请求，点开看Request Payload和Response两个标签页。Request Payload确认参数传对了没有，Response确认API到底返回了什么。九成的“翻译没反应”都能在这一步定位到原因。我还在代码里保留了一行console.log('API响应:', data)，平时注释掉，调试的时候取消注释，挺方便。有读者在反馈里说他的浏览器不支持async/await，我建议他先检查浏览器版本，2024年了还在用老版本IE的话，这个教程确实帮不上忙。
3.2 API密钥安全与请求频率控制
密钥安全这事我得先泼盆冷水。但凡把API密钥写在前端代码里，它就一定是暴露的。别人打开开发者工具就能看到你的config.js文件内容，或者在Network面板里直接看到请求头里带的密钥。我做这个简单网页的时候心里清楚这一点，教程定位就是本地学习项目，密钥额度小、用完就停，风险可控。你要是打算把网页挂到公网上让不特定的人用，千万别直接把自己的付费密钥放进去。正经做法是加一个后端服务做转发，前端把文字发给你的后端，后端拿着密钥去调翻译API再把结果传回来。多写一个后端接口，密钥就藏在服务器环境变量里了，前端代码干干净净。
讨论密钥安全的时候我顺带说说频率控制。翻译按钮我加了一层防抖，用户快速连点的时候，按钮的disabled属性能挡住重复请求。这还不够，我在doTranslate函数开头又加了一个时间戳判断，距离上一次请求不到500毫秒就直接return。原因是disabled属性在某些浏览器里响应没那么快，鼠标连点两下的间隔可能比属性更新的速度快。API免费额度一般按请求次数或者字符数计算，我见过有人测试的时候狂点按钮，一分钟消耗掉当天一半的免费额度，第二天打开网页发现翻译全挂了，还以为API服务商跑路了。我自己在代码里加了一个简单的计数器，每发一次请求就在localStorage里记一笔，页面上角落显示“今日已翻译X次”，心里有个数。
密钥管理上我做了两件小事。一件是把config.js加进了.gitignore文件，用Git管理代码的时候密钥文件不会被提交上去。另一件是单独留了一个config.example.js文件，里面只写const API_KEY = '在这里填你的密钥';，读者克隆代码后把文件名改成config.js再填自己的密钥。这个做法是从开源项目里学来的，成本几乎为零，能避免新手把密钥推到GitHub上被爬虫扫走。我查过一次，GitHub上每天都有大量新提交的API密钥被自动化脚本抓取，很多是学生上传课程作业时不小心带上去的。别当那个倒霉蛋。
3.3 网页部署方式与访问入口配置
部署这个简单网页，我试了三种方式，每种花的时间都没超过十分钟。最省事的是GitHub Pages，把代码推到GitHub仓库，在仓库设置里找到Pages选项，选一下分支，等一两分钟就能通过用户名.github.io/仓库名访问了。完全免费，适合纯静态页面。缺点是仓库必须是公开的，密钥文件不能推上去，正好跟我前面说的.gitignore配合着用。我在教程里把GitHub Pages放在推荐第一位，零成本、零配置、读者跟着点几下鼠标就能上线。Vercel和Netlify我也试了，流程比GitHub Pages多一步授权登录，好处是支持自定义域名和自动HTTPS，部署速度也快那么一丢丢。对新手来说差别不大，挑一个顺手的用就行。
部署过程中我遇到过两个小问题，都不致命但挺耽误时间。一个是文件路径问题，本地测试的时候<script src="./js/script.js">能正常加载，部署到GitHub Pages之后页面空白。打开控制台发现404，原因是仓库设置成了项目页面，访问地址带了子路径，相对路径解析出了偏差。把./改成绝对路径或者调整仓库设置为用户页面就解决了。另一个问题是HTTPS，Vercel和Netlify默认给你配了HTTPS，GitHub Pages也支持，不用自己折腾证书。我提这一嘴是因为有些翻译API要求请求来源必须是HTTPS，用HTTP协议部署的页面调API会被拒绝。部署完在浏览器地址栏看一眼有没有小锁图标，有锁就说明HTTPS生效了。
访问入口配置这块，我的建议是别一上来就买域名。GitHub Pages给的默认域名虽然长了点，但完全能用。想弄个短一点的入口，可以在域名服务商那里买个便宜域名，在GitHub Pages设置里填上自定义域名，再按提示加一条CNAME记录，十分钟搞定。我给这个翻译网页配过一个.top域名，首年花了几块钱，纯粹为了发给朋友的时候地址好看点。实际使用上跟默认域名没区别，翻译速度取决于API服务商，跟你的域名没关系。教程读者做到这一步，已经有一个能公网访问的翻译工具了，发给同学朋友用完全没问题。
3.4 从简单网页到可扩展翻译工具的优化方向
这个简单网页跑通之后，我脑子里冒出过一堆扩展想法。按实现成本从低到高排了排，发现有些改动十几行代码就能搞定，有些得重构整个项目。最容易加的是翻译历史记录，每次翻译完把原文和译文存进localStorage，页面上加一个侧边栏或者折叠面板展示最近二十条。我花了一个晚上做出来了，实际用起来挺方便，翻之前翻过的句子不用重新输入。再往上走一步是收藏功能，给历史记录每条加个星标按钮，收藏的内容单独存一个数组。这两个功能加起来代码量不到一百行，对教程读者来说是很好的练手项目。
批量翻译是个分水岭。单段文本翻译和批量翻译在交互上完全是两码事，得考虑文件上传、进度条、结果导出这些环节。我试过做一个支持上传.txt文件、按行拆分、逐行调API、最后打包成压缩包下载的版本，代码写到一半发现要处理的问题比预想的多得多——API调用频率控制、失败重试、结果顺序错乱、大文件内存占用。那次的教训是，功能扩展得跟着实际需求走，没人要求批量翻译的话，先把单段翻译打磨好更实在。真想往这个方向走，后端服务基本跑不掉，前端直接调API的简单模式撑不住复杂场景。
技术架构上的优化方向我也琢磨过。现在这个版本是纯前端加API直连，适合个人使用和小范围分享。用户量稍微大一点，就得把API调用挪到后端，前端只负责界面。后端可以用Node.js写一个简单的Express接口，几十行代码的事，部署到Render或者Railway的免费套餐上。再往后可以考虑加用户系统、翻译记忆库、术语表定制这些企业级功能，那是另一个量级的产品了。我在教程结尾留了一段话给读者：这个简单网页的价值不在于功能多全，而在于它把“输入文字—调API—展示结果”这条核心链路完整跑通了。把这条链路吃透，换任何翻译API、加任何新功能，都是在这条链路上做加减法。我自己就是从这个不到两百行代码的小项目开始，慢慢摸清了前端调API的各种门道。
