企业官网建设流程全解析

1. 项目概述：为什么一个“新闻应用”需要被拆解成“碎片”来实践？

“碎片实践-新闻应用”这个标题乍看有点拗口，但如果你在内容平台、资讯类App或媒体技术团队里干过几年，第一反应不是困惑，而是点头——对，就是它。这不是在做一个完整的新闻客户端，也不是复刻某家主流媒体的整套采编发流程，而是在用“碎片化”的思路，把新闻应用背后那些被默认打包交付的模块，一个个拎出来单独打磨、验证、组合。核心关键词就三个：碎片化、新闻、实践。它解决的不是“要不要做新闻应用”这种战略问题，而是“今天下午能不能跑通一条真实新闻从抓取到推送到测试设备的最小闭环”这种战术问题。

我带过几个模拟项目X的前端小组，也帮某高校实验室做过轻量级校园资讯聚合Demo，发现新手最容易卡在“一上来就想搭完整架构”：先建用户系统，再搞后台CMS，接着对接第三方API，最后才想到“哦，新闻内容本身怎么呈现？”结果两周过去，连一条带标题、摘要、发布时间的卡片都没渲染出来。而“碎片实践”的逻辑正好反过来——它默认你手头只有20分钟、一台笔记本、一个能联网的浏览器。你要做的，是立刻让“新闻”这件事发生：比如，用5行代码调通某公开新闻接口，把返回的JSON里第一条新闻的标题打印在控制台；再花10分钟，把它变成一个带点击跳转的HTML列表；第三步，加个本地缓存，让刷新页面后数据还在。每一步都小，但每一步都“可运行、可验证、可截图”。它不追求功能完整，但追求认知闭环。适合谁？刚学完HTTP请求的新手想验证所学；有经验的开发者想快速验证某个新API的稳定性；产品同学想用手动方式走一遍信息流逻辑，避免纸上谈兵；甚至UI设计师，也能用这个方法，只聚焦“新闻卡片在不同屏幕尺寸下的断点表现”，而不被登录态、推送权限这些干扰项带偏。它本质上是一种“最小可行性认知训练”，把新闻应用这个庞然大物，还原成一组可触摸、可调试、可失败的小单元。

2. 内容整体设计与思路拆解：为什么非得“碎片”，而不是直接上手做App？

2.1 “碎片”不是偷懒，而是对抗新闻应用的三大固有复杂性

新闻应用表面看只是“展示文字和图片”，但实际落地时，它天然裹挟着三重复杂性，直接上手做完整App，等于在沼泽地里盖楼。

第一重是数据源的不可控性。你以为新闻数据是稳定可靠的？错。真实场景里，你依赖的API可能今天返回20条，明天因限流只给3条；字段名可能上周叫publish_time，这周突然改成published_at；更常见的是，某条新闻的content字段里混进了未转义的HTML标签，直接innerHTML渲染会导致整个页面布局崩塌。如果一开始就埋头写用户登录、评论系统，等你终于连上数据源，发现第一条新闻就让首页白屏，挫败感会直接劝退。而碎片实践的第一步，就是专门处理这个：只写一个独立的fetchNews.js文件，目标明确——无论数据格式怎么变，它必须把原始响应转换成一个结构统一、字段干净、类型确定的JavaScript对象数组。这个过程逼你直面数据契约的脆弱性，而不是躲在“等后端改好接口”的借口里。

第二重是交互路径的强依赖性。新闻应用的典型路径是“列表页→详情页→分享/收藏→返回列表”。但新手常犯的错误，是把这四个环节当成原子操作一次性实现。结果就是：列表页的滚动加载还没调好，详情页的图片懒加载就卡死；分享按钮的逻辑写了一半，发现根本没处理微信SDK的异步初始化时机。碎片实践则强制你把路径“切片”：今天只做“列表页无限滚动”，目标是滑到底部自动触发下一页请求，并且保证请求不重复、不丢失；明天只做“详情页图片占位与加载状态反馈”，用纯CSS实现骨架屏，用loading="lazy"和onload事件控制真实图片替换。每个切片都独立验证，互不污染。我试过，用这种方法，一个零基础的实习生，三天内就能交出两个完全可用、无明显Bug的交互模块，而传统方式下，他可能还在纠结路由配置报错。

第三重是环境与权限的隐性门槛。做个新闻App，你以为只需要写代码？不，你还得搞定HTTPS证书（否则现代浏览器会拦截API请求）、处理iOS的ATS限制、适配Android的Scoped Storage、申请通知权限、配置深链接。这些不是“功能”，而是“通行许可”。碎片实践的聪明之处，在于它允许你绕开这些——初期所有测试都在localhost:3000下进行，用CORS代理解决跨域；图片资源全用CDN上的公开示例图；推送功能干脆用console.log('模拟推送已发送')代替。它不是否认这些环节的重要性，而是把它们从“启动障碍”降级为“后续扩展项”。等你的核心新闻流逻辑跑通了，再回头补证书、配权限，心态完全不同：前者是“我连门都进不去”，后者是“我的房子主体建好了，现在装门窗”。

2.2 “实践”二字的真正含义：拒绝Demo式演示，拥抱生产级思维

很多人把“实践”理解成“做个能跑起来的Demo”。这是最大的误区。“碎片实践”的“实践”，指的是用生产环境的标准去要求每一个碎片。举个具体例子：碎片之一是“新闻时间戳格式化”。新手通常写个new Date().toLocaleString()就交差。但真实新闻应用里，这行代码会出大问题——不同地区用户的toLocaleString()返回格式天差地别（美国是12/25/2023, 3:45 PM，德国是25.12.2023, 15:45），而编辑后台录入的时间可能是ISO格式2023-12-25T15:45:00Z，也可能带有时区偏移2023-12-25T15:45:00+08:00。一个合格的碎片，必须覆盖：

• 输入兼容性：能解析ISO、Unix时间戳、常见中文格式（如“2023年12月25日 15:45”）；
• 输出一致性：固定输出为“12月25日 15:45”这种无歧义格式；
• 时区鲁棒性：明确以服务端时间为准，不依赖用户本地时区；
• 性能考量：格式化函数不能成为列表渲染的性能瓶颈，需做memoization缓存。

我见过最典型的反面案例，是某公司内部资讯工具上线后，用户投诉“新闻发布时间显示错误”。排查发现，开发写的格式化函数在Chrome里正常，在Safari里却把所有时间都显示为“Invalid Date”。原因？他用了Date.parse()去解析ISO字符串，而老版Safari对带毫秒的ISO格式支持不全。这个坑，如果在碎片阶段就用真实设备（包括旧版iOS）做交叉测试，根本不会留到上线。所以，“实践”的核心，是把每一个看似简单的功能点，都当作一个微型产品来对待：有输入边界测试、有输出质量要求、有兼容性清单、有性能基线。它不追求功能多，但追求每个功能都经得起推敲。

2.3 整体架构选型：为什么放弃React/Vue全家桶，回归原生JS+轻量工具链？

看到“新闻应用”，很多人的第一反应是“用Vue CLI搭个脚手架，配个Vuex管理状态，再接个Axios”。这没错，但对于碎片实践，它是个陷阱。理由很实在：脚手架的启动成本，远高于一个碎片的学习成本。

我们算笔账。用Vue CLI创建一个新项目，执行vue create news-fragment，光是npm install依赖，就要下载几百MB的node_modules，耗时3-5分钟；然后要配置vue.config.js解决跨域；要写main.js挂载根实例；要建components/NewsList.vue文件；要写<template>、<script>、<style>三块；最后还要npm run serve启动开发服务器。而一个碎片的目标，可能只是“把JSON数据渲染成带样式的HTML列表”。用原生JS，你只需要：

1. 创建一个index.html；
2. 在<body>里放一个<div id="news-list"></div>；
3. 写一个<script>标签，里面fetch()数据，forEach()生成<li>，innerHTML塞进去；
4. 用<style>写几行CSS控制间距和字体。

全程5分钟，零依赖，双击index.html就能在浏览器里看到效果。更重要的是，它强迫你直面底层机制：fetch的Promise链怎么处理错误？innerHTML的XSS风险怎么规避？CSS选择器的层叠规则如何影响卡片高度？这些在框架里被封装掉的细节，恰恰是理解新闻应用本质的关键。当然，这不意味着永远不用框架。当碎片积累到一定数量（比如你有了5个独立验证过的模块：列表渲染、详情页、搜索过滤、本地缓存、离线阅读），再用Vite或Parcel把这些碎片“组装”成一个真正的App，会异常顺畅——因为你已经知道每个模块的输入输出契约，组装只是胶水代码，而非重新发明轮子。我自己的经验是：前3个碎片用原生JS，第4个开始引入TypeScript做类型约束，第6个再接入一个轻量状态库（如Valtio），节奏由认知负荷决定，而非工具流行度。

3. 核心细节解析与实操要点：五个必练碎片及其避坑指南

3.1 碎片一：新闻数据抓取与清洗（fetchNews.js）

这是整个链条的源头，也是最容易翻车的第一环。它的核心任务不是“拿到数据”，而是“拿到干净、可靠、结构一致的数据”。

实操步骤与关键代码：

// fetchNews.js export async function fetchNews(page = 1, pageSize = 10) { const url = `https://api.example-news.com/v1/articles?page=${page}&limit=${pageSize}`; try { const response = await fetch(url, { method: 'GET', headers: { 'Accept': 'application/json', // 某些API需要key，这里用环境变量避免硬编码 'Authorization': `Bearer ${import.meta.env.VITE_NEWS_API_KEY || ''}` } }); // 第一层校验：HTTP状态码 if (!response.ok) { throw new Error(`HTTP error! status: ${response.status}`); } const rawData = await response.json(); // 第二层校验：数据结构是否存在 if (!Array.isArray(rawData.data) && !rawData.articles) { throw new Error('Unexpected API response structure: missing "data" or "articles" array'); } // 第三层校验：字段健壮性清洗（核心！） const cleanArticles = (rawData.data || rawData.articles).map(item => ({ id: String(item.id || item.article_id || Date.now() + Math.random()), title: String(item.title || item.headline || '无标题新闻').trim().substring(0, 100), summary: String(item.summary || item.description || '').trim().substring(0, 200), // 时间戳处理：优先用published_at， fallback到created_at，最后用当前时间 publishTime: parseISODate(item.published_at || item.created_at || new Date().toISOString()), imageUrl: String(item.image_url || item.thumbnail || '').trim() || null, source: String(item.source || item.publisher || '未知来源').trim() })); return { articles: cleanArticles, total: Number(rawData.total || rawData.count || cleanArticles.length), page, pageSize }; } catch (error) { console.error('News fetch failed:', error); // 返回一个兜底的、结构正确的空数据，避免上游组件崩溃 return { articles: [], total: 0, page, pageSize }; } } // 独立的日期解析函数，处理各种混乱格式 function parseISODate(dateStr) { if (!dateStr) return new Date(); // 尝试标准ISO const isoDate = new Date(dateStr); if (!isNaN(isoDate.getTime())) return isoDate; // 尝试常见中文格式 "2023-12-25 15:45:00" const cnMatch = dateStr.match(/(\d{4})-(\d{1,2})-(\d{1,2})\s+(\d{1,2}):(\d{1,2}):(\d{1,2})/); if (cnMatch) { return new Date(cnMatch[1], cnMatch[2] - 1, cnMatch[3], cnMatch[4], cnMatch[5], cnMatch[6]); } // 兜底：返回当前时间 return new Date(); }

避坑指南（血泪经验）：

提示：永远不要信任API文档里的“示例响应”。我踩过最深的坑，是某新闻API文档写着“publish_time字段为ISO格式”，结果上线后发现，90%的体育新闻用的是ISO，但10%的突发新闻，编辑手动录入的是“2023年12月25日 下午3:45”，导致时间解析全部失败。解决方案？在parseISODate里必须加入正则匹配中文日期的分支，哪怕文档没写。碎片的价值，就在于逼你为这种“文档没说但现实存在”的情况提前写防御代码。

注意：fetch的mode: 'cors'是默认值，但如果你用file://协议直接打开HTML（比如双击运行），CORS会被浏览器阻止。此时碎片实践的正确做法，不是立刻换Web服务器，而是加一个开发时的代理开关：

// 开发时用代理，生产时直连 const baseUrl = import.meta.env.DEV ? 'http://localhost:8080/api/proxy' : 'https://api.example-news.com/v1';

这样，你既能快速验证逻辑，又为后续接入真实代理服务器留好接口。

3.2 碎片二：新闻卡片渲染与响应式布局（NewsCard.css+renderCard.js）

新闻的“颜值”决定了用户是否愿意停留。这个碎片不追求炫酷动画，只聚焦两件事：信息层级清晰、在任何设备上都可读。

核心CSS原则（非框架，纯CSS）：

/* NewsCard.css */ .news-card { display: flex; flex-direction: column; border-radius: 8px; overflow: hidden; box-shadow: 0 2px 8px rgba(0,0,0,0.08); transition: transform 0.2s, box-shadow 0.2s; } .news-card:hover { transform: translateY(-2px); box-shadow: 0 4px 16px rgba(0,0,0,0.12); } .news-card__image { width: 100%; height: 180px; object-fit: cover; background-color: #f0f0f0; /* 占位色 */ } .news-card__content { padding: 16px; flex: 1; display: flex; flex-direction: column; } .news-card__title { font-size: 1.25rem; font-weight: 700; line-height: 1.4; margin-bottom: 8px; color: #1a1a1a; } .news-card__summary { font-size: 0.95rem; line-height: 1.5; color: #4a4a4a; margin-bottom: 12px; /* 超出两行显示省略号 */ display: -webkit-box; -webkit-line-clamp: 2; -webkit-box-orient: vertical; overflow: hidden; } .news-card__meta { display: flex; justify-content: space-between; align-items: center; font-size: 0.85rem; color: #777; } /* 响应式断点 */ @media (max-width: 768px) { .news-card__image { height: 140px; } .news-card__title { font-size: 1.1rem; } .news-card__content { padding: 12px; } } @media (max-width: 480px) { .news-card__image { height: 120px; } .news-card__title { font-size: 1rem; } .news-card__summary { font-size: 0.85rem; } }

渲染逻辑（renderCard.js）：

export function renderCard(article) { const card = document.createElement('article'); card.className = 'news-card'; card.innerHTML = ` <img src="${article.imageUrl || '/placeholder.jpg'}" alt="${article.title}" class="news-card__image" loading="lazy" onerror="this.src='/placeholder.jpg'"> <div class="news-card__content"> <h3 class="news-card__title">${escapeHtml(article.title)}</h3> <p class="news-card__summary">${escapeHtml(article.summary)}</p> <div class="news-card__meta"> <span>${formatTimeAgo(article.publishTime)}</span> <span>${article.source}</span> </div> </div> `; return card; } // XSS防护：对用户输入内容做HTML转义 function escapeHtml(text) { const div = document.createElement('div'); div.textContent = text; return div.innerHTML; } // 时间格式化：显示“2小时前”、“昨天”、“12月25日” function formatTimeAgo(date) { const now = new Date(); const diffMs = now - date; const diffDays = Math.floor(diffMs / (1000 * 60 * 60 * 24)); if (diffDays === 0) { return '今天'; } else if (diffDays === 1) { return '昨天'; } else if (diffDays < 7) { return `${diffDays}天前`; } else { return `${date.getMonth() + 1}月${date.getDate()}日`; } }

避坑指南（实测心得）：

提示：loading="lazy"是浏览器原生支持的图片懒加载，但它有个隐藏坑：在某些安卓WebView里，首次滚动时图片可能闪烁或加载延迟。解决方案？给.news-card__image加一个min-height: 120px的占位，确保容器高度稳定，避免布局抖动。碎片实践教会你，一个CSS属性的取舍，背后是无数种终端的兼容性博弈。

注意：onerror="this.src='/placeholder.jpg'"这种内联JS虽然不优雅，但在碎片阶段是最快捷的容错方案。等你进入组装阶段，再用addEventListener('error', ...)重构也不迟。关键是先让“图片加载失败”这个场景有明确、可验证的处理逻辑，而不是让它静默失败。

3.3 碎片三：新闻列表分页与无限滚动（infiniteScroll.js）

新闻是持续更新的，用户不会手动点“下一页”。这个碎片的目标，是让用户滑动到底部时，平滑加载下一批数据，且不打断当前浏览。

核心实现逻辑：

// infiniteScroll.js export class InfiniteScroll { constructor(container, loadMoreCallback) { this.container = container; this.loadMoreCallback = loadMoreCallback; this.isLoading = false; this.isEnd = false; this.page = 1; this.pageSize = 10; this.init(); } init() { // 使用Intersection Observer API，比监听scroll事件更高效 this.observer = new IntersectionObserver( (entries) => { if (entries[0].isIntersecting && !this.isLoading && !this.isEnd) { this.loadMore(); } }, { rootMargin: '0px 0px 200px 0px' // 提前200px触发加载 } ); // 观察容器底部的占位元素 const sentinel = document.createElement('div'); sentinel.className = 'infinite-scroll-sentinel'; this.container.appendChild(sentinel); this.observer.observe(sentinel); } async loadMore() { if (this.isLoading || this.isEnd) return; this.isLoading = true; try { const data = await this.loadMoreCallback(this.page, this.pageSize); // 渲染新数据 data.articles.forEach(article => { const card = renderCard(article); this.container.appendChild(card); }); this.page++; // 判断是否还有更多数据 if (data.articles.length < this.pageSize || data.page * this.pageSize >= data.total) { this.isEnd = true; // 显示“没有更多了”提示 this.showEndMessage(); } } catch (error) { console.error('Load more failed:', error); // 错误时，至少要停止加载状态，避免用户以为还在转圈 this.isLoading = false; } } showEndMessage() { const endMsg = document.createElement('div'); endMsg.className = 'infinite-scroll-end'; endMsg.textContent = '没有更多新闻了'; this.container.appendChild(endMsg); } } // 使用示例 const newsList = document.getElementById('news-list'); const infiniteScroll = new InfiniteScroll(newsList, fetchNews);

避坑指南（踩坑实录）：

提示：rootMargin: '0px 0px 200px 0px'这个参数是精髓。如果设成'0px'，意味着用户必须把滚动条拉到最底部，图片才开始加载，体验极差。设成200px，用户离底部还有200像素时就开始请求，数据基本能在滚动到时就绪。我实测过，200px是多数手机屏幕高度的1/3，是一个平衡“提前量”和“不浪费请求”的黄金值。

注意：IntersectionObserver在老版iOS Safari（< 12.2）中不支持。碎片实践的应对策略不是放弃，而是优雅降级：检测API是否存在，不存在时，回退到传统的scroll事件监听，并添加防抖（debounce）：

if ('IntersectionObserver' in window) { // 用Observer } else { // 用scroll + debounce let scrollTimer; window.addEventListener('scroll', () => { clearTimeout(scrollTimer); scrollTimer = setTimeout(() => { if (isScrolledToBottom()) this.loadMore(); }, 100); }); }

碎片的意义，就是让你为每一个“不支持”场景，都准备好一个明确的Plan B。

3.4 碎片四：本地新闻缓存与离线访问（newsCache.js）

新闻不是实时的，用户可能在地铁里、电梯中打开App。这个碎片解决的核心问题是：“当网络断开时，用户还能看到什么？”

核心策略：双缓存层

• 内存缓存（短期）：用Map存储最近请求的页面数据，避免重复请求。
• 持久化缓存（长期）：用localStorage存储精选新闻（如头条、本地要闻），并设置过期时间。

// newsCache.js export class NewsCache { constructor() { this.memoryCache = new Map(); // key: 'page_1', value: {data, timestamp} this.storageKey = 'news_cache_v1'; } // 内存缓存：5分钟有效 getFromMemory(key) { const item = this.memoryCache.get(key); if (item && Date.now() - item.timestamp < 5 * 60 * 1000) { return item.data; } this.memoryCache.delete(key); return null; } setToMemory(key, data) { this.memoryCache.set(key, { data, timestamp: Date.now() }); } // 持久化缓存：24小时有效，仅存精选 async getFromStorage() { try { const cached = localStorage.getItem(this.storageKey); if (!cached) return null; const parsed = JSON.parse(cached); if (Date.now() - parsed.timestamp > 24 * 60 * 60 * 1000) { localStorage.removeItem(this.storageKey); return null; } return parsed.data; } catch (e) { console.error('Failed to read from localStorage', e); return null; } } async setToStorage(data) { try { localStorage.setItem(this.storageKey, JSON.stringify({ data, timestamp: Date.now() })); } catch (e) { // localStorage满时会抛错，静默处理 console.warn('localStorage is full, skip caching'); } } // 主入口：先查内存，再查storage，最后才请求网络 async getCachedOrFetch(key, fetchFn) { // 1. 查内存 const memoryData = this.getFromMemory(key); if (memoryData) return memoryData; // 2. 查storage（仅对首页等关键页） if (key === 'page_1') { const storageData = await this.getFromStorage(); if (storageData) return storageData; } // 3. 网络请求 const networkData = await fetchFn(); // 4. 缓存到内存和storage this.setToMemory(key, networkData); if (key === 'page_1') { await this.setToStorage(networkData.articles.slice(0, 5)); // 只存前5条 } return networkData; } } // 使用示例 const cache = new NewsCache(); const data = await cache.getCachedOrFetch('page_1', () => fetchNews(1, 10));

避坑指南（独家技巧）：

提示：localStorage的容量限制是5MB，但新闻JSON体积不小。我试过，一条带长摘要和图片URL的新闻，JSON序列化后约2KB，100条就是200KB，完全够用。但关键是要主动清理。碎片实践里，我加了一个pruneOldCache()方法，每次存新数据前，检查总大小，超过4MB就删除最老的缓存项。这个逻辑在完整App里常被忽略，导致缓存越积越多，最终setItem直接失败。

注意：fetch请求本身有浏览器缓存，但默认不缓存POST，且对Cache-Control头敏感。碎片实践的建议是：显式禁用浏览器缓存，完全由自己的NewsCache控制。在fetch请求头里加上'Cache-Control': 'no-cache'，避免浏览器和自定义缓存逻辑打架。这是很多开发者调试时百思不得其解“为什么缓存没生效”的根源。

3.5 碎片五：新闻搜索与关键词高亮（searchNews.js）

用户不会记住所有新闻标题，他们习惯搜索。这个碎片不追求全文检索引擎，而是用前端最朴素的方式，实现“输入即搜、即时高亮”。

核心算法：

• 模糊匹配：不苛求完全一致，支持“北”匹配“北京”、“新冠”匹配“新型冠状病毒”。
• 高亮渲染：用<mark>标签包裹匹配词，CSS控制样式。

// searchNews.js export function searchArticles(articles, keyword) { if (!keyword || keyword.trim() === '') return articles; const normalizedKeyword = keyword.trim().toLowerCase(); return articles.filter(article => { const searchableText = [ article.title, article.summary, article.source ].join(' ').toLowerCase(); // 简单的包含匹配（生产环境可升级为Levenshtein距离） return searchableText.includes(normalizedKeyword); }).map(article => { // 高亮处理：对标题和摘要中的关键词加<mark> const highlightText = (text) => { if (!text || !normalizedKeyword) return text; const regex = new RegExp(`(${normalizedKeyword})`, 'gi'); return text.replace(regex, '<mark>$1</mark>'); }; return { ...article, highlightedTitle: highlightText(article.title), highlightedSummary: highlightText(article.summary) }; }); } // 渲染时使用 function renderSearchResult(article) { return ` <article class="news-card"> <h3 class="news-card__title">${article.highlightedTitle}</h3> <p class="news-card__summary">${article.highlightedSummary}</p> <!-- 其他字段 --> </article> `; }

避坑指南（实战优化）：

提示：<mark>标签的默认样式是黄色背景，在深色模式下几乎看不见。碎片实践必须考虑主题适配。解决方案？在CSS里加一行：

@media (prefers-color-scheme: dark) { mark { background-color: #ffcc00; color: #000; } }

这行代码很小，但它代表了“用户真实场景”的意识——不是所有用户都用亮色主题。

注意：搜索框的input事件非常频繁，如果每次按键都触发searchArticles，性能会爆炸。必须加防抖（debounce）。但碎片实践的更高阶技巧是：只对长度>=2的关键词搜索。因为单个字（如“北”）匹配结果太多，毫无意义，且计算量大。在searchArticles函数开头加一句：

if (keyword.length < 2) return []; // 或者返回空数组，或原始数组

这个小判断，能让搜索响应速度提升一个数量级。

4. 实操过程与核心环节实现：从零开始，30分钟搭建一个可运行的新闻碎片沙盒

4.1 环境准备：零依赖，一个文件夹足矣

不需要Node.js，不需要npm，不需要任何构建工具。打开你的文件管理器，新建一个文件夹，命名为news-fragments。里面只需要三个文件：

news-fragments/ ├── index.html # 主页面，加载所有碎片 ├── style.css # 全局样式，含NewsCard.css └── script.js # 主逻辑，整合所有碎片

index.html（精简版）：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>新闻碎片沙盒</title> <link rel="stylesheet" href="style.css"> </head> <body> <header class="app-header"> <h1>📰 新闻碎片沙盒</h1> <input type="text" id="search-input" placeholder="搜索新闻..." /> </header> <main class="app-main"> <div id="news-list" class="news-list"></div> </main> <footer class="app-footer"> <p>碎片实践 · 新闻应用 | 当前状态：<span id="status">准备就绪</span></p> </footer> <script type="module" src="script.js"></script> </body> </html>

为什么用type="module"？因为它原生支持ES6的import/export，让你能直接把前面写的fetchNews.js、renderCard.js等碎片文件，像搭积木一样导入。这是现代浏览器给前端开发者的最大红利，碎片实践必须用上。

4.2 核心整合：script.js——把五个碎片串成一条流水线

// script.js import { fetchNews } from './fetchNews.js'; import { renderCard } from './renderCard.js'; import { InfiniteScroll } from './infiniteScroll.js'; import { NewsCache } from './newsCache.js'; import { searchArticles } from './searchNews.js'; // 初始化缓存 const cache = new NewsCache(); // DOM元素 const newsList = document.getElementById('news-list'); const searchInput = document.getElementById('search-input'); const statusEl = document.getElementById('status'); // 状态管理（简化版） let currentArticles = []; let isSearching = false; // 首次加载 async function loadInitialNews() { setStatus('正在加载新闻...'); try { // 使用缓存策略 const data = await cache.getCachedOrFetch('page_1', () => fetchNews(1, 10)); currentArticles = data.articles; renderNewsList(currentArticles); setStatus(`加载成功：${data.articles.length} 条新闻`); // 启动无限滚动 new InfiniteScroll(newsList, async (page, size) => { setStatus(`加载第${page}页...`); const data = await fetchNews(page, size); return data; }); } catch (error) { setStatus(`加载失败：${error.message}`); console.error(error); } } // 渲染列表 function renderNewsList(articles) { newsList.innerHTML = ''; articles.forEach(article => { const card = renderCard(article); newsList.appendChild(card); }); } // 搜索逻辑 searchInput.addEventListener('input', debounce((e) => { const keyword = e.target.value.trim(); if (keyword === '') { isSearching = false; renderNewsList(currentArticles); setStatus('已取消搜索'); return; } isSearching = true; const results = searchArticles(currentArticles, keyword); renderNewsList(results); setStatus(`搜索到 ${results.length} 条结果`); }, 300)); // 工具函数：防抖 function debounce(func, wait) { let timeout; return function executedFunction() { const later = () => { clearTimeout(timeout); func(...arguments); }; clearTimeout(timeout); timeout = setTimeout(later, wait); }; } // 状态提示 function setStatus(text) { statusEl.textContent = text; } // 启动 document.addEventListener('DOMContentLoaded', loadInitialNews);

关键细节说明：

• import路径：所有碎片文件（fetchNews.js等）都放在同一目录下，路径是相对的./fetchNews.js。这是ES Module的规范，也是碎片可移植性的基础——任何一个碎片，只要import语句正确