企业官网建设流程全解析

1. 从“artcraft”这个名字说起：它到底想解决什么问题

第一次看到“artcraft”这个标题，我脑子里蹦出来的第一反应是“艺术”加“手艺”的组合词。直觉告诉我，这不是一个纯技术框架的名字，也不是某个具体产品的品牌名，它更像是一种定位——把艺术化的表达和工程化的手艺捏在一起。后来跟几个做独立开发的朋友聊，发现大家对这个词的理解出奇一致：它代表的是那种既追求视觉与体验上的美感，又强调代码和实现上的扎实的项目类型。

那这类项目通常出现在什么场景里？我梳理了一下自己接触过的案例，大致集中在三个方向。第一类是创意工具类应用，比如给设计师用的配色生成器、给插画师用的笔刷管理器、给手工爱好者用的图纸辅助工具。第二类是内容展示型站点，比如个人作品集、小型展览的线上展厅、手作店铺的商品页。第三类是交互式小玩意，比如网页上的粒子动画、可拖拽的拼贴画板、生成艺术的小实验。

这些场景有一个共同点：它们对“好看”和“好用”的要求几乎一样高。纯技术项目可以容忍界面丑一点，纯设计项目可以容忍实现糙一点，但 artcraft 类项目不行。用户第一眼看到的是视觉，第二秒感受到的是交互，第三秒才会去琢磨背后的逻辑。所以这类项目的核心矛盾往往不是“能不能实现”，而是“怎么在有限的时间和精力里，把美感和功能同时做到位”。

这篇文章适合谁看？如果你正在做一个个人作品集、一个创意小工具、或者任何需要“拿得出手”的 side project，那接下来的内容应该能帮你少走一些弯路。如果你只是对“艺术与工程结合”这个话题感兴趣，也可以当故事看。我会从整体设计思路、核心技术细节、实操流程、常见坑四个层面展开，尽量把每个选择背后的“为什么”讲清楚。

2. 整体设计与思路拆解：为什么这样搭架子

2.1 先定调性，再定技术栈

很多人做 artcraft 类项目时容易犯一个错误：先选技术栈，再想做什么。比如“我最近在学 React，那就用 React 做个作品集吧”，或者“听说 Three.js 很酷，那就做个 3D 展示”。这种思路不是不行，但很容易导致技术压过内容——最后做出来的东西技术很炫，但跟你想表达的主题没什么关系。

我的习惯是反过来：先用一句话描述这个项目给人的感觉。比如“像一个安静的纸质手账本”、“像走进一间暖光下的陶艺工作室”、“像翻一本有质感的摄影杂志”。这句话定下来之后，再去选技术方案。如果感觉是“纸质手账本”，那可能就不需要复杂的 3D 效果，反而要在字体、纸张纹理、翻页动效上下功夫。如果感觉是“陶艺工作室”，那暖色调、柔和阴影、缓慢的过渡动画就比炫酷的粒子效果更合适。

这个“定调性”的步骤看起来有点虚，但它能帮你省掉大量后期返工。我见过太多项目做到一半发现“风格不统一”，然后被迫大改。与其这样，不如一开始就花半小时想清楚。

2.2 技术选型的三个考量维度

定完调性之后，技术选型我一般看三个维度：上手成本、可控性、生态丰富度。这三个维度在不同项目里的权重不一样，需要根据实际情况权衡。

上手成本很好理解，就是你或者你的团队需要花多少时间才能开始产出。如果是一个周末项目，那肯定选自己最熟的工具。如果是想学新东西，那可以适当选一个学习曲线陡一点但更有趣的方案。可控性指的是你能不能精细地控制每一个像素、每一帧动画。有些框架封装得太好，改起来反而麻烦。生态丰富度则决定了你遇到问题时能不能快速找到解决方案，以及能不能方便地集成第三方库。

拿一个具体的例子来说。假设你要做一个可交互的拼贴画板，用户可以从素材库里拖拽元素、调整大小和旋转、最后导出图片。这时候你有几个选择：用原生 Canvas API 自己画，用 Fabric.js 这类 Canvas 库，或者用 SVG 加 DOM 操作。原生 Canvas 可控性最高，但每一件事都要自己写，上手成本高。Fabric.js 提供了现成的对象模型和交互控制，上手快，但遇到它没覆盖的需求时改起来比较费劲。SVG 加 DOM 的好处是每个元素都是真实的 DOM 节点，事件处理和样式控制很直观，但元素一多性能就会下降。

我个人的经验是：如果交互逻辑复杂但元素数量不多（比如少于 200 个），优先考虑 SVG 加 DOM；如果元素数量多或者需要像素级操作，那就上 Canvas。这个判断标准不是绝对的，但能覆盖大部分 artcraft 类项目的需求。

2.3 视觉层与逻辑层的分离策略

artcraft 类项目还有一个特点：视觉层的变化频率远高于逻辑层。今天觉得按钮圆角好看，明天想改成直角；今天用蓝色主调，明天想换成橙色。如果视觉和逻辑混在一起写，每次改样式都要动核心代码，很容易引入 bug。

我的做法是把视觉相关的配置抽成一个独立的模块。这个模块可以是一个 JSON 文件、一个 JavaScript 对象、或者一组 CSS 变量。里面放颜色、间距、字体、圆角、阴影、动画时长这些“可调参数”。逻辑层只负责“什么时候显示什么”，不关心“显示成什么样”。这样改视觉的时候只需要动一个地方，而且不容易影响功能。

举个例子，假设你有一个卡片组件。逻辑层只负责“根据数据渲染 N 张卡片”，视觉层则定义卡片的背景色、边框、阴影、内边距、标题字号。如果哪天想把卡片从“扁平风”改成“拟物风”，只需要改视觉配置里的阴影和边框参数，逻辑代码一行都不用动。这个策略在项目后期尤其重要，因为那时候你已经没有精力去小心翼翼地改每一处样式了。

3. 核心细节解析与实操要点：把美感落到代码里

3.1 字体与排版：最容易被忽视的质感来源

很多开发者做 artcraft 类项目时，会把大量精力花在动画和交互上，却忽略了字体和排版才是第一眼质感的决定因素。我见过不少项目，动效做得很花哨，但字体用的是系统默认，行高挤在一起，段落宽度横跨整个屏幕，读起来非常累。

字体选择上，我的建议是最多用两种字体：一种用于标题，一种用于正文。标题字体可以有个性一点，比如衬线体或者手写体；正文字体一定要易读，无衬线体通常更安全。如果不想引入外部字体文件，也可以用系统字体栈，但要注意不同平台的渲染差异。比如同样一套字体栈，在某个桌面系统上可能显示为一种无衬线体，在另一个系统上可能显示为另一种，行高和字重都会变。

排版方面，有几个参数我每次都会调。行高一般设为字号的 1.5 到 1.8 倍，正文取上限，标题取下限。段落宽度控制在 60 到 75 个字符之间，太宽眼睛容易串行，太窄会频繁换行。段落间距至少是行高的 0.5 倍，否则段落之间会粘在一起。这些数字不是死的，但可以作为起点。

注意：如果你用了自定义字体，一定要设置font-display: swap，否则字体加载期间文字会不可见，用户会看到一片空白。这个细节在移动网络下尤其重要。

3.2 色彩系统：从“凭感觉”到“有依据”

色彩是 artcraft 类项目的灵魂，但也是最容易翻车的地方。很多人选颜色靠感觉，今天觉得这个蓝好看就用这个蓝，明天觉得那个橙不错就加个橙，最后整个页面像打翻了调色盘。

我的做法是先定一个主色，然后基于主色生成一套完整的色彩系统。具体来说，主色确定后，用 HSL 色彩模式调整明度和饱和度，生成 5 到 7 个层级。比如主色是hsl(210, 70%, 50%)，那浅色背景可以是hsl(210, 70%, 95%)，深色文字可以是hsl(210, 70%, 20%)，悬停状态可以是hsl(210, 70%, 45%)。这样整套颜色看起来是“一家人”，不会打架。

中性色（灰阶）同样重要。我一般会准备 4 到 5 个灰阶，从接近白到接近黑。这些灰色不要用纯灰，而是带一点主色的色相。比如主色是蓝色，那灰色就用带一点蓝的灰，这样整体会更协调。这个技巧在 UI 设计里很常见，但很多开发者不知道。

还有一个容易被忽略的点是对比度。正文文字和背景的对比度至少要达到 4.5:1，大号文字可以放宽到 3:1。这个标准是为了保证可读性，尤其是在户外或者低亮度屏幕上。你可以用在线工具检查对比度，也可以自己算，但一定要检查。我见过太多项目因为对比度不够，在别人的屏幕上看起来一团糊。

3.3 动效设计：少即是多，慢即是快

artcraft 类项目通常会有一些动效，比如页面切换、元素出现、悬停反馈。动效做得好，项目会显得很“贵”；做得不好，会显得很“廉价”。我的经验是：动效要少、要慢、要有目的。

“少”指的是不要每个元素都加动画。如果一个页面里所有东西都在动，用户会不知道看哪里。通常只需要给关键元素加动效，比如主标题、主要按钮、核心图片。“慢”指的是动画时长不要太短。很多开发者习惯用 0.1 秒或 0.2 秒，这在交互反馈里没问题，但在 artcraft 类项目里会显得很仓促。我一般用 0.3 到 0.6 秒，让动画有“呼吸感”。“有目的”指的是每个动画都要有理由：这个动画是为了引导注意力，还是为了表达层级关系，还是为了提供反馈？如果找不到理由，那就不加。

缓动函数的选择也很关键。默认的ease其实不太自然，我一般用cubic-bezier(0.4, 0, 0.2, 1)作为标准缓动，进入动画用cubic-bezier(0, 0, 0.2, 1)，退出动画用cubic-bezier(0.4, 0, 1, 1)。这几个曲线在大多数场景下都比默认值更舒服。

提示：如果你不确定动画时长和缓动是否合适，可以放慢到 0.5 倍速反复看几遍。很多问题在慢速下会暴露出来，比如元素重叠、位置跳动、颜色突变。

3.4 响应式布局：不只是“能看”，还要“好看”

artcraft 类项目通常需要在不同设备上展示，但很多开发者只做到了“能看”，没有做到“好看”。比如在手机上，字体大小没调，行高没改，图片没裁切，结果就是文字挤在一起，图片比例奇怪。

我的做法是为每个断点单独设计，而不是简单缩放。具体来说，桌面端可能是三栏布局，平板端变成两栏，手机端变成单栏。字体大小也要跟着变，桌面端正文 16px，手机端可以降到 14px，但行高要保持比例。图片方面，桌面端可以用宽幅横图，手机端可以裁成方形或者竖图，而不是把横图硬缩。

还有一个细节是触摸目标的大小。在手机上，按钮和链接的可点击区域至少要 44x44 像素，否则用户很难点准。这个标准是苹果提出来的，但安卓和网页上也适用。我见过不少项目在手机上按钮太小，用户点几次点不中就直接放弃了。

4. 实操过程与核心环节实现：从零搭一个 artcraft 项目

4.1 项目初始化与目录结构

假设我们要做一个个人手作作品集，展示一些手工皮具的照片和制作过程。这个项目不需要后端，纯静态站点就够。技术栈我选Vite + 原生 JavaScript + CSS，不引入框架。为什么不用框架？因为页面不多，交互也不复杂，引入框架反而增加构建体积和心智负担。Vite 提供了开发服务器和打包功能，原生 JS 和 CSS 足够应付这个场景。

目录结构我一般这样组织：

project/ ├── index.html ├── src/ │ ├── main.js │ ├── styles/ │ │ ├── base.css │ │ ├── layout.css │ │ └── components.css │ ├── data/ │ │ └── works.json │ └── assets/ │ ├── images/ │ └── fonts/ └── public/

base.css放重置样式和全局变量，layout.css放页面骨架，components.css放卡片、按钮、导航这些组件。works.json存作品数据，包括标题、描述、图片路径、制作日期。这样以后加新作品只需要改 JSON 文件，不用动代码。

4.2 数据驱动的作品展示

作品展示是这个项目的核心。我不用手写 HTML，而是用 JavaScript 从works.json读取数据，动态生成卡片。这样做的好处是加作品不用改 HTML，而且以后想换布局只需要改生成逻辑。

// main.js async function loadWorks() { const response = await fetch('/src/data/works.json'); const works = await response.json(); const container = document.querySelector('.works-grid'); works.forEach(work => { const card = document.createElement('article'); card.className = 'work-card'; card.innerHTML = ` <div class="work-card__image"> <img src="${work.image}" alt="${work.title}" loading="lazy"> </div> <div class="work-card__info"> <h3>${work.title}</h3> <p>${work.description}</p> <time>${work.date}</time> </div> `; container.appendChild(card); }); }

这里有几个细节值得说。loading="lazy"让图片进入视口才加载，能显著提升首屏速度。<time>标签虽然视觉上跟<span>没区别，但对可访问性有好处，屏幕阅读器能识别出这是日期。卡片用<article>而不是<div>，语义更清晰。

4.3 图片处理与性能优化

手作作品集通常图片很多，而且都是高分辨率照片。如果不处理，页面会非常重。我的做法是在构建时生成多套尺寸的图片，然后用srcset让浏览器自己选。

比如一张原图是 2000px 宽，我会生成 400px、800px、1200px、1600px 四个版本。HTML 里这样写：

<img src="image-800.jpg" srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w, image-1600.jpg 1600w" sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw" alt="作品描述" loading="lazy" >

sizes告诉浏览器在不同屏幕宽度下图片会占多宽，浏览器据此选择最合适的版本。这个方案比单纯用 CSS 缩放要高效得多，因为用户不会下载用不到的大图。

图片格式上，我优先用WebP，因为它在同等质量下比 JPEG 小 25% 到 35%。如果担心兼容性，可以用<picture>标签提供 JPEG 作为回退。不过现在主流浏览器都支持 WebP 了，回退方案可以酌情省略。

注意：图片压缩不要压得太狠。手作类项目的图片质感很重要，压得太狠会出现色块和模糊。我一般用质量 80 到 85 的 WebP，肉眼几乎看不出区别，但体积能小很多。

4.4 页面过渡与滚动动效

为了让页面更有“手作感”，我加了一些轻微的滚动动效。具体来说，当卡片进入视口时，从下方淡入并轻微上移。这个效果用IntersectionObserver实现，不需要引入动画库。

const observer = new IntersectionObserver((entries) => { entries.forEach(entry => { if (entry.isIntersecting) { entry.target.classList.add('is-visible'); observer.unobserve(entry.target); } }); }, { threshold: 0.1 }); document.querySelectorAll('.work-card').forEach(card => { observer.observe(card); });

CSS 里定义初始状态和可见状态：

.work-card { opacity: 0; transform: translateY(20px); transition: opacity 0.6s cubic-bezier(0.4, 0, 0.2, 1), transform 0.6s cubic-bezier(0.4, 0, 0.2, 1); } .work-card.is-visible { opacity: 1; transform: translateY(0); }

threshold: 0.1表示元素露出 10% 就触发，这个值比较自然。如果设成 0.5，用户要滚到一半才看到动画，会显得迟钝。unobserve在触发后取消监听，避免重复触发。

4.5 字体加载与回退策略

如果项目用了自定义字体，加载策略很重要。我的做法是用font-display: swap加上系统字体回退。这样字体加载期间用户看到的是系统字体，加载完成后自动切换，不会出现空白。

@font-face { font-family: 'CustomSerif'; src: url('/assets/fonts/custom-serif.woff2') format('woff2'); font-display: swap; } body { font-family: 'CustomSerif', Georgia, 'Times New Roman', serif; }

回退字体要选一个跟自定义字体风格接近的。如果自定义字体是衬线体，回退就用 Georgia 或 Times；如果是无衬线体，回退就用系统默认的无衬线体。这样切换时视觉差异不会太大。

还有一个技巧是预加载关键字体。在<head>里加一行：

<link rel="preload" href="/assets/fonts/custom-serif.woff2" as="font" type="font/woff2" crossorigin>

这能让浏览器更早开始下载字体，减少切换时的闪烁。不过预加载不要滥用，只预加载首屏用到的字体，否则会跟其他资源抢带宽。

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

5.1 动效卡顿：先查属性，再查数量

动效卡顿是 artcraft 类项目最常见的问题。排查思路我一般分两步：先看动画用了哪些 CSS 属性，再看同时动画的元素有多少。

如果动画用了width、height、top、left、margin这些属性，那大概率会卡。因为这些属性会触发浏览器的布局重算，开销很大。解决办法是改用transform和opacity，这两个属性只触发合成，性能好得多。比如把left: 100px改成transform: translateX(100px)，把width: 200px改成transform: scaleX(2)。

如果属性没问题但还是一卡一卡的，那可能是同时动画的元素太多。比如一个列表里有 50 个卡片同时淡入，浏览器要同时处理 50 个合成层，压力很大。解决办法是错开动画时间，给每个卡片加一个递增的transition-delay，比如第一个 0ms，第二个 50ms，第三个 100ms，以此类推。这样动画会像波浪一样依次出现，既好看又流畅。

5.2 图片模糊：检查设备像素比

在高分屏上图片模糊，通常是因为只提供了一张低分辨率图。比如图片实际显示宽度是 400px，但你只提供了 400px 的图，在 2 倍屏上浏览器会把 400px 的图拉伸到 800px 显示，自然就模糊了。

解决办法是用srcset提供 2 倍甚至 3 倍的图。如果不想生成太多版本，至少提供 2 倍图。判断标准是：图片的物理像素宽度应该大于等于显示宽度乘以设备像素比。比如显示宽度 400px，设备像素比 2，那图片至少要是 800px 宽。

还有一个容易忽略的点是SVG 的模糊。SVG 本身是矢量，不会模糊，但如果你给 SVG 设置了固定的width和height，而viewBox的比例跟它不一致，浏览器会拉伸导致模糊。解决办法是保持viewBox和实际尺寸的比例一致，或者用preserveAspectRatio控制缩放行为。

5.3 颜色在不同屏幕上不一致

同一个颜色在不同屏幕上看起来不一样，这是硬件差异导致的，无法完全消除，但可以缓解。我的做法是避免使用纯黑和纯白。纯黑#000在 OLED 屏幕上会显得特别刺眼，纯白#fff在低亮度屏幕上会显得发灰。用接近黑的深灰（比如#1a1a1a）和接近白的浅灰（比如#f5f5f5）会舒服很多。

另外，避免使用高饱和度的纯色。比如纯红#ff0000、纯绿#00ff00、纯蓝#0000ff，这些颜色在不同屏幕上的表现差异很大。用稍微降低饱和度的版本，比如#e63946、#2a9d8f、#457b9d，会稳定得多。

如果项目对颜色准确性要求很高，可以考虑用Display P3 色彩空间，但兼容性有限，需要提供 sRGB 回退。对于大多数 artcraft 类项目来说，用 sRGB 加上合理的颜色选择就足够了。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑是过度依赖 CSS 框架。早期我做 artcraft 类项目时喜欢用现成的 UI 框架，觉得省事。但后来发现，这些框架的默认样式往往跟项目调性不符，改起来比自己写还麻烦。而且框架的组件通常带有自己的设计语言，混在一起容易显得杂乱。现在我更倾向于只引入重置样式，其他全部自己写。虽然前期慢一点，但后期可控性高很多。

第二个坑是忽略无障碍性。artcraft 类项目往往注重视觉，容易忽略屏幕阅读器用户。比如图片没有alt，按钮没有aria-label，颜色对比度不够。这些问题在视觉上看不出来，但对一部分用户来说是致命的。我现在养成的习惯是：每写完一个组件，就用键盘 Tab 键走一遍，看看焦点顺序是否合理，焦点样式是否可见。再用屏幕阅读器模拟器读一遍，看看信息是否完整。

第三个坑是在移动端测试太晚。桌面端开发时一切正常，到手机上发现布局全乱、字体太小、按钮点不中。后来我改成每完成一个模块就在手机上测一次，而不是全部做完再测。这样问题能及时发现，修复成本也低。Chrome DevTools 的设备模拟功能很好用，但真机测试还是不可替代，尤其是触摸交互和性能表现。

6. 工具选型与效率提升：我常用的几类工具

6.1 设计与原型工具

做 artcraft 类项目，前期用设计工具把视觉定下来能省很多时间。我常用的是Figma，因为它免费、跨平台、协作方便。我一般会先画一个简单的风格板，放上主色、辅色、字体样本、按钮样式、卡片样式。这个风格板不需要很精细，但能帮我在写代码时保持一致性。

如果不想用在线工具，Penpot是一个不错的开源替代品，功能跟 Figma 类似，但可以自己部署。对于注重隐私或者网络环境不稳定的场景，Penpot 更合适。

原型方面，我一般不做高保真原型，因为 artcraft 类项目的很多细节（比如动效手感）在原型里很难体现。我更喜欢直接用代码做原型，改一行刷新就能看到效果，比在原型工具里拖拽快得多。

6.2 图片处理工具

图片处理我主要用Squoosh，这是一个在线工具，可以压缩图片、转换格式、调整尺寸。它的优点是界面直观，能实时看到压缩前后的对比，而且完全在浏览器里运行，图片不会上传到服务器。对于批量处理，我会用Sharp这个 Node.js 库写一个脚本，一次性生成多套尺寸和格式。

// 批量生成图片尺寸 const sharp = require('sharp'); const fs = require('fs'); const path = require('path'); const sizes = [400, 800, 1200, 1600]; const inputDir = './assets/originals'; const outputDir = './assets/images'; fs.readdirSync(inputDir).forEach(file => { const inputPath = path.join(inputDir, file); const name = path.parse(file).name; sizes.forEach(size => { sharp(inputPath) .resize(size) .webp({ quality: 82 }) .toFile(path.join(outputDir, `${name}-${size}.webp`)); }); });

这个脚本跑一遍，所有图片的多个尺寸就都生成好了。quality: 82是我试过很多次之后觉得比较平衡的值，再低会出现可见的压缩痕迹，再高体积又上去了。

6.3 性能检测工具

性能检测我主要用Lighthouse，它集成在 Chrome DevTools 里，跑一遍就能看到性能、可访问性、最佳实践、SEO 四个维度的评分。我一般关注三个指标：首次内容绘制（FCP）、最大内容绘制（LCP）、累积布局偏移（CLS）。FCP 应该在 1.8 秒以内，LCP 在 2.5 秒以内，CLS 小于 0.1。

如果 LCP 不达标，通常是首屏大图或字体加载太慢。解决办法是预加载关键资源、压缩图片、用font-display: swap。如果 CLS 不达标，通常是图片没有设置宽高，加载时把内容挤下去了。解决办法是给所有图片设置width和height属性，或者用 CSSaspect-ratio占位。

还有一个工具是WebPageTest，它能模拟不同网络环境和设备，给出更详细的加载瀑布图。不过它需要上传代码或者提供公开链接，对于本地开发不太方便。我一般在项目上线前用它做一次全面检测。

6.4 版本控制与部署

版本控制我不用多说，Git 是标配。但 artcraft 类项目有一个特殊需求：图片和字体文件通常比较大，直接放进 Git 仓库会让仓库体积膨胀。我的做法是用Git LFS管理大文件，或者干脆把图片放在对象存储里，仓库里只存路径。

部署方面，静态站点我推荐Netlify或Vercel，它们都支持从 Git 仓库自动构建和部署，而且有免费额度。如果项目需要自定义域名和 HTTPS，它们也都能一键配置。对于国内访问速度有要求的场景，可以考虑Cloudflare Pages，它的 CDN 覆盖比较广。

提示：部署前记得跑一遍构建，检查有没有遗漏的资源或错误的路径。我遇到过好几次本地开发正常，部署后图片 404，原因是路径用了绝对路径但部署环境有子目录。解决办法是统一用相对路径，或者在构建时注入基础路径。

7. 内容扩展与长期维护：让项目活得更久

7.1 数据与视图的进一步分离

项目上线后，你可能会想加新作品、改描述、换封面图。如果每次都要改代码再部署，会很麻烦。我的做法是把作品数据抽到一个独立的 JSON 文件或者无头 CMS 里。JSON 文件适合作品不多、更新频率低的情况。如果作品很多或者需要多人协作，可以考虑用Contentful、Sanity这类无头 CMS，它们提供可视化编辑界面，非技术人员也能更新内容。

无头 CMS 的好处是内容与代码完全分离，改内容不需要重新部署。坏处是引入了一个外部依赖，如果服务挂了或者网络不通，内容就加载不出来。我的折中方案是构建时拉取数据，生成静态页面。这样既有 CMS 的编辑便利，又有静态站点的稳定性。具体做法是在构建脚本里调用 CMS 的 API，把数据写进 JSON 文件，然后正常构建。

7.2 渐进增强与降级策略

artcraft 类项目往往依赖一些现代浏览器特性，比如IntersectionObserver、CSS Grid、WebP。如果用户用的是旧浏览器，可能会看到错乱或者空白。我的做法是渐进增强：核心内容用最基础的技术实现，确保任何浏览器都能看到；高级效果作为增强，不支持就跳过。

比如滚动动效，如果浏览器不支持IntersectionObserver，那就不加动画，直接显示内容。图片格式，如果浏览器不支持 WebP，就用<picture>回退到 JPEG。CSS Grid 不支持就用 Flexbox 或者浮动布局。这些降级方案不需要很完美，只要保证内容可读、功能可用就行。

判断浏览器支持情况可以用Can I Use这个网站，或者用Modernizr在运行时检测。我一般用 CSS 的@supports规则做特性检测，比 JavaScript 检测更简洁。

@supports (display: grid) { .works-grid { display: grid; grid-template-columns: repeat(auto-fill, minmax(300px, 1fr)); } } @supports not (display: grid) { .works-grid { display: flex; flex-wrap: wrap; } .work-card { width: calc(33.333% - 20px); } }

7.3 定期回顾与迭代

artcraft 类项目不是做完就扔的，它需要定期回顾和迭代。我一般每三个月会看一遍，检查几个方面：内容是否过时、链接是否失效、性能是否下降、视觉是否还符合当前审美。内容过时就更新，链接失效就修复或删除，性能下降就重新优化图片和代码，视觉过时就调整配色和排版。

迭代的时候不要一次改太多，每次只改一个方面，改完测试一遍。这样如果出问题，很容易定位是哪个改动导致的。我见过有人一次性改版，结果出了 bug 不知道是哪里的问题，只能全部回滚，浪费了很多时间。

还有一个习惯是记录每次改动。我会在项目根目录放一个CHANGELOG.md，简单记一下每次改了什么、为什么改。这个习惯在项目搁置一段时间后重新捡起来时特别有用，能快速回忆起之前的决策背景。

7.4 分享与反馈

项目做完后，我建议分享出去，收集反馈。可以发给朋友看，也可以发到设计或开发社区。反馈不一定要全盘接受，但能帮你发现一些自己没注意到的问题。比如别人可能觉得某个颜色太刺眼，或者某个交互不直观，或者某个页面在手机上加载太慢。这些问题你自己用的时候可能习惯了，但新用户会立刻感受到。

收集反馈时，我一般会问三个问题：第一眼看到什么？哪里让你困惑？哪里让你觉得不舒服？这三个问题能覆盖大部分体验问题。不要问“你觉得怎么样”，这种问题得到的回答通常是“挺好的”，没有实际价值。

8. 我个人在实际操作中的几点体会

做 artcraft 类项目这些年，最大的体会是克制比堆砌更难，也更值得。刚开始做的时候总想加很多东西：加个粒子背景、加个 3D 旋转、加个视差滚动。后来发现，这些东西加进去之后，项目反而变得嘈杂，用户不知道看哪里。真正好的 artcraft 项目，往往是做减法做出来的。每个元素都有存在的理由，每个动效都有明确的目的，没有多余的东西。

另一个体会是手感和直觉需要时间积累。配色好不好看、动画快慢是否合适、间距是否舒服，这些没有公式可循，只能靠大量看和做来培养。我的建议是多看好作品，多拆解。看到喜欢的网站或应用，用开发者工具看看它的颜色值、字体、间距、动画时长。看得多了，自然就有感觉了。

最后一个体会是不要追求完美，先做出来。我见过太多人卡在“选哪个字体”或者“用哪个颜色”上，项目迟迟没有进展。其实第一版不需要完美，先做出来，用起来，然后再慢慢调。调的时候你会发现，很多之前纠结的问题在实际使用中根本不存在，而一些之前没注意到的问题反而很突出。先完成，再完美，这个顺序不能反。