企业官网建设流程全解析

1. 从“i-have-adhd”说起：一个标签背后的真实需求

第一次看到“i-have-adhd”这个项目标题，我脑子里蹦出来的不是某个具体的技术栈，而是一类非常典型的现象级需求——用极简的方式，把一种难以言说的状态“标签化”。ADHD，注意力缺陷与多动障碍，在当下的互联网语境里早就不是医学教科书上的专有名词了，它变成了一种自我描述、一种社交货币，甚至是一种自嘲式的身份认同。你随便打开一个内容社区，搜“ADHD”，能看到大量“确诊了”“我怀疑我是”“这就是我”的帖子。而“i-have-adhd”这个标题，恰恰踩中了这个情绪点：它不是在讲病理，而是在讲一种“我就是这样”的宣告。

那这个项目到底能做什么？从标题本身和它背后的热词生态来看，它大概率是一个轻量级的自我表达工具——可能是一个网页小应用、一个浏览器插件、一个命令行小脚本，甚至只是一个静态页面。它的核心功能，我推测是让用户以极低的成本生成一个“我有ADHD”的视觉标识或状态卡片，用于社交平台分享、个人主页装饰，或者纯粹作为一种情绪出口。它解决的问题很具体：当你想表达“我的大脑运行方式跟别人不太一样”时，你不需要写一篇长文解释，只需要一个标签、一张图、一个链接。

适合谁来参考？三类人。第一类是对前端轻量级项目感兴趣、想练手一个完整小产品的开发者；第二类是对ADHD话题有共鸣、想做一个属于自己的表达工具的创作者；第三类是做社区运营或内容策划的人，想理解为什么一个简单的标签能引发传播。不管你是哪一类，这个项目的核心价值都不在技术复杂度，而在于它精准地捕捉了一个真实存在的情绪需求，并用最低的成本把它产品化了。

我之所以对这个标题感兴趣，是因为它代表了一种“反宏大叙事”的产品思路。现在太多项目一上来就讲平台、讲生态、讲全链路，但“i-have-adhd”这种标题告诉你：有时候一个词、一个状态、一个瞬间的共鸣，就足够撑起一个有人用的东西。接下来我会从设计思路、技术选型、实操实现、问题排查几个层面，把这个项目拆开揉碎，让你看完就能自己复现一个类似的轻量级表达工具。

2. 内容整体设计与思路拆解

2.1 为什么是“标签化表达”而不是“功能堆砌”

做这类项目，最容易掉进去的坑就是“功能蔓延”。你一开始只是想做一个“我有ADHD”的标签生成器，结果做着做着就想加用户系统、加历史记录、加多语言、加主题切换，最后变成一个四不像。我在实际动手之前，先问了自己一个问题：用户来到这个页面，最核心的动作是什么？答案很简单——输入几个字，得到一个可以分享的视觉结果。所有不服务于这个动作的功能，都应该砍掉。

这个判断背后有一个很朴素的逻辑：ADHD人群本身就有注意力难以持续的特点，如果你的工具需要用户填五个表单、点三次确认、等两秒加载，那它本身就违背了目标用户的体验习惯。所以整个设计的第一原则是“一步到位”。用户打开页面，看到一个输入框，输入自己的名字或者一句想说的话，点击生成，立刻得到一张带有“i-have-adhd”标识的卡片。没有注册，没有登录，没有多余跳转。

这个思路跟现在流行的“微工具”趋势是一致的。你看那些传播量大的小项目，往往都是单点功能做到极致。比如一个只做图片压缩的网站，一个只做二维码生成的页面，一个只做倒计时的应用。它们不追求大而全，追求的是“我打开你，三秒内解决问题，然后关掉”。这种克制本身就是一种产品能力。

2.2 视觉风格的选择：为什么“粗糙感”反而更有效

确定了功能极简之后，下一个要决策的是视觉风格。我试过三种方向：第一种是精致的卡片设计，圆角、阴影、渐变、品牌字体；第二种是极简的黑白文字，像终端输出；第三种是带一点“手写感”或“涂鸦感”的粗糙风格。实测下来，第三种传播效果最好。

原因不复杂。ADHD在社交语境里往往带有一种“我不完美但我接受”的自我和解意味。如果你把它做得太精致、太商业，反而失去了那种“真实感”。粗糙感传递的信号是：这是一个真实的人做出来的东西，不是某个大厂的设计规范。用户分享的时候，心理负担更低，因为它看起来不像广告，更像一个表情包或者一句吐槽。

具体到实现上，我用了系统默认的无衬线字体，没有引入任何外部字体文件。背景色用了偏暖的米白，而不是纯白，减少屏幕刺眼感。文字颜色是深灰而不是纯黑，整体对比度控制在舒适区间。卡片边缘没有做圆角，保留了直角，配合轻微的噪点纹理，营造一种“打印出来贴在墙上”的质感。这些选择单独看都很小，但叠加在一起，就形成了统一的调性。

注意：视觉风格没有绝对的对错，但一定要和目标用户的情绪状态匹配。如果你的项目是面向ADHD群体的，那就不要用那种高饱和度、强对比、闪烁动画的设计，那只会加重视觉负担。

2.3 技术选型的底层逻辑：为什么不用框架

这个项目我最终选择的是纯HTML加CSS加原生JavaScript，没有用任何前端框架。很多人可能会觉得奇怪，现在React、Vue这么成熟，为什么还要手写？理由有三个。

第一，体积。整个项目打包出来不到10KB，加载速度极快。对于这种“打开即用”的工具，首屏时间每多100毫秒，跳出率就会明显上升。框架带来的运行时开销，在这个场景下是纯粹的负担。

第二，部署成本。纯静态文件可以直接扔到任何静态托管服务上，不需要构建步骤，不需要Node环境，不需要CI/CD。我甚至可以直接把文件拖到浏览器里打开就能用。对于个人项目来说，维护成本越低，你越有可能持续迭代。

第三，可控性。没有框架的抽象层，每一个DOM操作、每一个样式规则都在你的直接控制之下。你想改一个颜色，直接改CSS变量；你想加一个动画，直接写keyframes。不需要理解框架的更新机制、生命周期、响应式原理。对于这种规模的项目，原生技术栈的学习成本和调试成本都更低。

当然，这不是说框架不好。如果你的项目需要复杂的状态管理、路由、组件复用，那框架是更好的选择。但“i-have-adhd”这种单页单功能的工具，原生三件套就是最优解。工具选型永远要看场景，不要为了用而用。

3. 核心细节解析与实操要点

3.1 输入处理：如何让用户“随便输”也不出错

用户输入是这类工具最容易出问题的地方。你永远不知道用户会输入什么——空字符串、超长文本、特殊符号、表情符号、换行符，甚至直接粘贴一段HTML。如果处理不好，轻则显示错乱，重则XSS安全漏洞。

我的处理策略是“宽进严出”。输入框不做任何格式限制，用户可以随便打。但在生成卡片之前，做三层处理。第一层是trim，去掉首尾空白。第二层是长度截断，超过30个字符的部分直接截掉，并在末尾加省略号。第三层是转义，把所有HTML特殊字符替换成实体，确保插入DOM时不会被解析成标签。

function sanitizeInput(raw) { const trimmed = raw.trim(); const truncated = trimmed.length > 30 ? trimmed.slice(0, 30) + '...' : trimmed; const div = document.createElement('div'); div.textContent = truncated; return div.innerHTML; }

这段代码里，div.textContent的赋值和innerHTML的读取是关键。浏览器会自动把特殊字符转义，你拿到的是安全的HTML字符串。这比手写正则替换更可靠，也不容易漏掉某些边缘字符。

实操心得：不要用eval或者innerHTML直接插入用户输入。哪怕你觉得“这只是个小项目，没人会攻击”，养成安全习惯比什么都重要。我见过太多个人项目因为一个输入框没处理，被人注入脚本挂马。

3.2 卡片渲染：用Canvas还是DOM

生成分享卡片有两种主流方案：一种是DOM转图片，用html2canvas之类的库；另一种是直接用Canvas绘制。我两种都试过，最后选了Canvas。

DOM转图片的优点是开发快，你直接用HTML和CSS写卡片样式，然后调库截图。但缺点也很明显：库的体积大，html2canvas压缩后也有几十KB；渲染结果在不同浏览器上有差异，有时候字体、间距、阴影会对不上；而且它依赖DOM布局，如果页面有滚动或者隐藏元素，截图容易出问题。

Canvas方案正好相反。开发成本高一些，你需要手动计算每个文字的位置、大小、颜色，但换来的是完全可控的渲染结果。不管在什么浏览器上，只要Canvas API支持，出来的图一模一样。而且Canvas是浏览器原生能力，不需要引入任何外部依赖，项目体积可以压到极致。

我最终用Canvas绘制了三个元素：背景矩形、主标题文字、用户输入的文字。主标题用固定字号，用户文字根据长度动态调整字号，保证不溢出。绘制完成后，调用toDataURL导出PNG，用户可以直接右键保存或者长按分享。

function drawCard(ctx, userText) { const width = 600; const height = 400; // 背景 ctx.fillStyle = '#faf8f5'; ctx.fillRect(0, 0, width, height); // 主标题 ctx.fillStyle = '#2c2c2c'; ctx.font = 'bold 48px sans-serif'; ctx.textAlign = 'center'; ctx.fillText('i-have-adhd', width / 2, 160); // 用户文字，动态字号 const fontSize = userText.length > 15 ? 24 : 32; ctx.font = `${fontSize}px sans-serif`; ctx.fillStyle = '#555'; ctx.fillText(userText, width / 2, 260); }

这段代码里，textAlign = 'center'让文字水平居中，你只需要给x坐标传宽度的一半。动态字号的计算逻辑很简单：超过15个字符就用小一号的字，避免文字超出画布边界。实际测试下来，这个阈值在大多数情况下都能保证显示完整。

3.3 分享机制：如何让用户“愿意发出去”

生成卡片只是第一步，真正决定项目传播效果的是分享环节。如果用户生成之后还要下载、再打开社交软件、再上传，那流失率会非常高。所以我在页面上直接集成了两个分享入口：一个是“保存图片”，一个是“复制文案”。

保存图片很简单，把Canvas的toDataURL结果塞进一个<a>标签的href，加上download属性，用户点击就自动下载。复制文案则是把一段预设的文字加上用户输入的内容，写入剪贴板。文案我写得很直白：“我的大脑运行方式有点不一样。#i-have-adhd”。没有强行煽情，也没有过度解释，就是一句陈述。

async function copyText(userText) { const text = `${userText}\n我的大脑运行方式有点不一样。#i-have-adhd`; try { await navigator.clipboard.writeText(text); showToast('已复制'); } catch (err) { // 降级方案 const textarea = document.createElement('textarea'); textarea.value = text; document.body.appendChild(textarea); textarea.select(); document.execCommand('copy'); document.body.removeChild(textarea); showToast('已复制'); } }

这里用了navigator.clipboard，但加了降级处理。因为有些浏览器或者非HTTPS环境下，Clipboard API不可用，这时候回退到execCommand。虽然execCommand已经标记为废弃，但在兼容性场景下它仍然是可靠的备选。

注意：剪贴板操作必须由用户手势触发，比如点击事件。如果你在页面加载时自动调用，浏览器会拦截并报错。这是安全策略，不是bug。

4. 实操过程与核心环节实现

4.1 项目结构：三个文件搞定

整个项目的文件结构简单到不能再简单：

i-have-adhd/ ├── index.html ├── style.css └── app.js

index.html负责页面骨架，style.css负责视觉样式，app.js负责交互逻辑。没有构建工具，没有依赖管理，没有环境变量。你把这四个文件（加上一个favicon）放到任何静态服务器上就能跑。

这种极简结构的好处是，你可以在任何地方快速修改和部署。我试过在手机上用文本编辑器改代码，改完直接刷新浏览器就能看到效果。对于个人项目来说，降低“动手门槛”比追求工程规范更重要。你越容易开始改，就越有可能持续优化。

4.2 页面布局：移动端优先的思考

虽然这个工具在桌面端也能用，但我把移动端作为第一优先级来设计。原因很简单：分享行为主要发生在手机上。用户在社交媒体看到别人发的卡片，点进来，大概率也是用手机。如果页面在手机上显示错乱、按钮太小、输入框被键盘挡住，那整个体验就断了。

布局上我用了Flexbox纵向排列，从上到下依次是：标题区、输入区、预览区、操作区。每个区域之间用margin隔开，整体居中。输入框的font-size设为16px，这是iOS上的一个关键阈值——小于16px时，浏览器会自动放大页面，导致布局跳动。按钮的高度设为48px，这是触屏设备上比较舒适的点击区域。

.container { display: flex; flex-direction: column; align-items: center; padding: 24px 16px; max-width: 480px; margin: 0 auto; } .input-field { width: 100%; font-size: 16px; padding: 12px; border: 1px solid #ddd; border-radius: 4px; } .action-btn { width: 100%; height: 48px; font-size: 16px; margin-top: 12px; cursor: pointer; }

max-width: 480px配合margin: 0 auto，让页面在桌面端也不会拉得太宽，保持阅读舒适度。padding用了16px，这是移动端比较通用的边距值，既不会太挤，也不会浪费屏幕空间。

4.3 Canvas尺寸与导出参数

Canvas的尺寸设置有个容易踩的坑：如果你只设置width和height属性，不设置CSS样式，那Canvas在页面上会按照属性值显示，但在高DPI屏幕上会模糊。正确的做法是同时设置属性尺寸和CSS尺寸，并且考虑devicePixelRatio。

我的处理方式是：Canvas属性尺寸设为600x400，CSS尺寸也设为600x400，但在绘制之前，根据window.devicePixelRatio对上下文进行缩放。这样在Retina屏幕上，导出的图片依然清晰。

const canvas = document.getElementById('card'); const ctx = canvas.getContext('2d'); const dpr = window.devicePixelRatio || 1; canvas.width = 600 * dpr; canvas.height = 400 * dpr; canvas.style.width = '600px'; canvas.style.height = '400px'; ctx.scale(dpr, dpr);

导出的时候，toDataURL('image/png')默认就是无损格式。如果你想要更小的文件体积，可以用toDataURL('image/jpeg', 0.9)，但JPEG不支持透明背景，而且文字边缘会有压缩伪影。对于这种以文字为主的卡片，PNG是更好的选择，文件大小通常在50KB到100KB之间，完全在可接受范围内。

4.4 部署与托管：零成本上线

项目写完之后，部署是最简单的一步。因为它是纯静态文件，你可以选择任何静态托管服务。我个人的习惯是直接用对象存储加CDN，上传文件、开启静态网站托管、绑定域名，整个过程不超过十分钟。如果你不想买域名，很多平台也提供免费的二级域名，足够个人项目使用。

部署之后，我建议做一件事：在手机上实际打开一次，走一遍完整流程。输入文字、生成卡片、保存图片、复制文案。很多时候你在桌面浏览器上测试没问题，到了手机上就会发现按钮点不到、图片保存失败、剪贴板不工作。这些问题只有真机测试才能暴露出来。

实操心得：部署完成后，把链接发给两三个朋友，让他们用各自的手机试一遍。不同品牌、不同系统、不同浏览器的表现可能不一样。收集到的问题比你一个人测半天都多。

5. 常见问题与排查技巧实录

5.1 文字溢出画布怎么办

这是Canvas绘制中最常见的问题。用户输入的文字长度不确定，如果你用固定字号，长文本就会超出画布边界被截断。我的解决方案是动态计算字号，但更稳妥的做法是同时做“字号缩放”和“换行处理”。

字号缩放的逻辑前面已经说了，根据字符数分档。但分档有个问题：中英文混合时，字符宽度差异很大。一个中文字符的宽度大约等于两个英文字符。所以更精确的做法是用ctx.measureText测量实际宽度，然后反推字号。

function fitText(ctx, text, maxWidth, baseFontSize) { let fontSize = baseFontSize; ctx.font = `${fontSize}px sans-serif`; while (ctx.measureText(text).width > maxWidth && fontSize > 12) { fontSize -= 1; ctx.font = `${fontSize}px sans-serif`; } return fontSize; }

这个循环从基础字号开始，每次减1，直到文字宽度小于最大宽度或者字号降到12px为止。虽然效率不是最优，但对于这种单次绘制的场景完全够用。如果你追求性能，可以用二分查找，但代码会复杂一些，收益不大。

5.2 保存图片在部分浏览器失效

<a download>属性在大多数现代浏览器上都支持，但在某些移动端浏览器或者WebView里，点击下载链接可能没反应，或者直接在新标签页打开图片而不是下载。遇到这种情况，我的处理方式是检测download属性是否被支持，如果不支持，就引导用户长按图片保存。

function downloadImage(dataUrl) { const link = document.createElement('a'); link.href = dataUrl; link.download = 'i-have-adhd.png'; if (typeof link.download === 'undefined') { // 不支持download属性，打开新窗口让用户长按保存 window.open(dataUrl, '_blank'); } else { link.click(); } }

这个检测逻辑很简单，但能覆盖大部分场景。另外，有些浏览器对dataURL的长度有限制，如果图片太大可能会失败。这时候可以考虑用Blob加URL.createObjectURL的方式，把dataURL转成Blob URL再下载，兼容性更好。

5.3 页面加载后输入框没有自动聚焦

移动端浏览器出于性能考虑，通常不会自动弹出键盘，除非用户主动点击输入框。所以autofocus属性在移动端经常失效。这不是bug，是浏览器的策略。我的处理方式是在页面上放一个明显的提示文字，比如“点击下方输入框开始”，引导用户操作。同时把输入框的点击区域做大，确保用户第一次就能点中。

如果你确实想尝试自动聚焦，可以在页面加载后调用input.focus()，但不要抱太大期望。更好的做法是接受这个限制，把交互设计得足够直观，让用户不需要思考就知道下一步该做什么。

5.4 常见问题速查表

这张表里的问题，我在实际开发中都遇到过。最耗时的往往是那些“看起来很简单”的问题，比如忘记加viewport meta导致移动端显示比例不对，或者DOM还没加载完就绑定事件导致点击无效。这些坑不踩一遍很难记住，但踩过之后就会变成肌肉记忆。

6. 从“i-have-adhd”延伸：轻量级表达工具的通用方法论

做完这个项目之后，我回头想了想，它其实代表了一类可以复用的产品模式。我把它叫做“轻量级表达工具”——核心特征就三个：单点功能、零门槛使用、强分享属性。这类工具的技术实现往往不复杂，但产品判断很关键。

第一个判断是“情绪是否足够具体”。“i-have-adhd”之所以能成立，是因为它对应了一种具体的、有共鸣的情绪状态。如果你做一个“i-am-happy”，那就太宽泛了，用户不知道什么时候该用。越具体的情绪，越容易触发分享。比如“i-am-overthinking”“i-have-imposter-syndrome”“i-am-burnt-out”，这些都比泛泛的“i-am-sad”更有传播力。

第二个判断是“生成成本是否足够低”。用户从打开页面到得到结果，操作步骤不能超过三步。输入、点击、保存，三步之内完成。每多一步，流失率就翻倍。所以不要加登录、不要加设置、不要加预览确认。直接给结果，让用户自己决定要不要调整。

第三个判断是“结果是否适合公开分享”。生成的卡片不能包含隐私信息，不能有让人尴尬的内容，视觉上要足够“中性”以至于可以发在朋友圈、微博、小红书而不显得突兀。这也是为什么我选择了米白背景和深灰文字，而不是鲜艳的配色或者夸张的图形。

如果你想把这类工具做成一个系列，我的建议是共用一套底层代码，只替换文案和视觉主题。比如同一个Canvas绘制逻辑，换一个标题文字、换一个背景色、换一句分享文案，就是一个新的工具。这样你的边际成本极低，但可以覆盖多个情绪场景。当然，前提是每个场景都经过验证，确实有用户需求，而不是你自己拍脑袋想出来的。

最后分享一个我在实际运营中观察到的现象：这类工具的传播高峰往往出现在晚上十点到凌晨两点。这个时间段，人的情绪更敏感，表达欲更强，分享意愿也更高。如果你要做推广，可以在这个时间段集中发布内容或者引导用户分享。当然，这只是经验之谈，具体还要看你的目标用户活跃时间。

提示：不要试图在卡片上放你的品牌logo或者网址。用户分享的是情绪，不是你的广告。如果你非要加，放在页面底部就够了，不要污染卡片本身。