简介：个人新闻收集网站模板是一款面向个人博客、资讯收藏与新闻聚合页面的网页设计资源，适用于想快速搭建个人展示站的非专业开发者与网页设计学习者。资源共13个文件，压缩包仅24KB，包内以HTML主页、JPG/GIF图片素材、TXT说明文档为主，辅以URL快捷方式和系统配置文件，结构简洁清晰，便于直接修改后本地部署。模板设计上兼顾自定义化、多媒体展示与SEO基础优化，响应式设计可自适应手机、平板和电脑屏幕；用户无需深入编码，通过调整版块、更换配色、替换素材即可生成个性化新闻页。主页图片目录与使用说明文档相互配套，能帮助新手快速理解页面结构并完成内容替换。目前已有157人学习，适合个人站长、学生或初学网页设计者收藏参考。
1. 个人新闻收集网站模板：一个页面管住所有信息源
每天早上打开十几个标签页轮流刷新闻，同事最新的行业动态往往不是你第一个看到的——这种场景下，个人新闻收集网站模板就有用了。它本质上是一套帮你把散落在各个站点、RSS 源里的最新内容聚合到一个自己搭建的网页上的模板工程。有了它，订阅、采集、去重、展示的链路一次性打通，不用从零设计数据库和前后端。适合两类人：一种是不想依赖第三方聚合服务的个人读者，想完全掌控自己的信息源；另一种是刚入门想练手 Web 开发的从业者，拿这个模板当载体把「定时任务 + 数据存储 + Web 展示」整条链路串起来。本文要讲的就是这个模板背后的结构、启动步骤以及最容易翻车的地方。
2. 先把架构选对：个人新闻站的三种实现路线与取舍
2.1 从纯静态到重爬虫：三条路怎么选
做个人新闻收集网站，第一个要回答的问题是“我用什么当骨架”。我在实际动手时见过三种主流路线，它们各自的维护成本和能力上限差别很大。
路线一：纯静态生成。采集脚本定时运行，把最新的新闻渲染成一批静态 HTML 文件，再由 nginx 这类 Web 服务器托管。这是最省资源的方式，不需要任何常驻进程，服务器压力几乎为零。缺点是页面没有交互能力，想加个搜索框、分类切换，都得在前端用 JavaScript 硬撑，而且每次刷新都要重新生成页面。
路线二：轻量后端 + 文件数据库。这是个人站里最耐用的组合。后端用 Flask 这类轻量 Web 框架，数据库用 SQLite 单文件库。采集服务常驻内存，定时抓取后写入 SQLite，前端页面通过后端接口按需读取。相比纯静态，多了一层动态查询能力，但复杂度也就多在一个常驻进程的运维上。
路线三：重型爬虫框架 + 消息队列。用 Scrapy 配合 Redis、Celery 这类组件，可以做大规模分布式抓取。但个人站的源数量通常只有几十个，根本喂不饱这个架构。引入消息队列意味着要多维护两个常驻服务，出问题的概率翻倍。除非有上千个源，否则别选这条。
| 路线 | 部署成本 | 动态能力 | 适合场景 |
|---|---|---|---|
| 纯静态生成 | 最低 | 弱 | 纯展示、访问量小 |
| 轻量后端 + SQLite | 低 | 中 | 个人主流选择 |
| 重型爬虫 + 消息队列 | 高 | 强 | 多源大规模采集 |
我给这个模板定的基调就是路线二。理由很直白：一个人维护的站点，服务的故障面越小越好。Flask 加 SQLite 的服务，重启一次也就一两秒，数据文件拷走就能备份，这种量级的简单是重型方案给不了的。
2.2 拆解标准数据流：采集、去重、存储与渲染
模板的完整数据流可以用一条链路说清楚：RSS 源输入 → 采集解析 → 去重判断 → 写入数据库 → 后端查询 → 前端模板渲染 → 浏览器展示。
采集层的职责是定时去拉取订阅源的 RSS 或 Atom 内容。解析环节常见做法是用现成的解析库，把 XML 里的标题、链接、摘要、发布时间提取出来。这里要留个心眼：不同站点返回的格式五花八门，有的字段叫 summary，有的叫 description，有的时间字段是 RFC 822 格式，有的又是 ISO 8601。模板里应该在解析层统一做字段兜底和时间格式化，不然存进数据库的数据会在展示层全面失控。
去重层是模板里容易被人忽视、却最影响体验的环节。同一篇新闻经常被多个源转载，链接不同但标题一样，如果不做标题归一化去重，列表里就会出现大量重复内容。SQLite 建表时给 link 字段加唯一约束是基础防线，标题哈希是第二道防线，两道都做才能基本杜绝刷屏。
存储层用 SQLite 就够了，一条新闻对应一张表，带上来源、分类、抓取时间这几个字段。展示层由后端从数据库按时间倒序取数据，前端模板负责把数据渲染成卡片列表。整个链路里，前端的「新闻按时间线平铺」是最直观的形态，后面要加筛选、搜索也都在这个骨架上扩展。
3. 把模板跑起来：最小可用版从克隆到上线
3.1 项目结构与依赖安装
这个模板的项目结构我会保持在一个一眼能看懂的状态。后端入口、配置、采集模块、前端模板、静态资源各归各的目录，数据库单独放在 data 目录下方便备份。
news-template/ ├── app.py # Flask 主应用，注册路由 ├── config.py # 站点名称、源列表、刷新间隔 ├── fetcher/ │ ├── __init__.py │ ├── rss.py # RSS 抓取与解析 │ └── dedup.py # 标题归一化与去重 ├── templates/ │ └── index.html # 新闻列表页模板 ├── static/ │ └── style.css # 页面样式 ├── data/ │ └── news.db # 首次启动自动创建 ├── requirements.txt └── run.sh # 一键启动脚本依赖安装的步骤很简单，在项目根目录执行：
python3 -m venv .venv source .venv/bin/activate pip install flask feedparser requests逻辑说明：venv 是把 Python 环境隔离在项目目录里，避免和系统其它包互相污染。flask 提供 Web 服务，feedparser 负责解析 RSS/Atom，requests 用于在解析前手动拉取内容以便控制编码。requirements.txt 里就写这三个包名，不锁版本，装的时候取当前环境可用版本。
参数说明：如果机器上 Python 版本比较老，建议换成 python3 明确指定版本；Windows 下激活命令是.venv\Scripts\activate，别照抄 macOS 的命令。装完后用pip list看一眼包是否齐了，再继续下一步。
3.2 配置数据源：写你的第一份订阅列表
数据源是整个模板的心脏。我在 config.py 里把订阅源定义成一个列表，每个源包含显示名、RSS 地址和分类三段信息，实际内容如下：
# config.py SITE_NAME = "我的新闻站" # 页面标题和导航栏显示的名称 REFRESH_INTERVAL = 30 # 采集间隔，单位：分钟 PAGE_SIZE = 20 # 每页显示的新闻条数 NEWS_SOURCES = [ { "name": "某科技资讯站", "url": "https://example.com/rss", "category": "科技", }, { "name": "某开源社区", "url": "https://example.org/feed.xml", "category": "开发", }, ]逻辑说明：这段配置被采集模块和后端共用。采集模块遍历 NEWS_SOURCES 逐个拉取，后端渲染页面时读取 SITE_NAME 和 PAGE_SIZE。把配置集中在一个文件里，后续调参数不用翻代码。
参数说明：REFRESH_INTERVAL 的单位是分钟，个人站点建议设置在 30 以上。低于 10 分钟不仅容易触发源站的风控，而且绝大多数新闻源的更新频率根本没那么快，拉得太勤只是白费资源。url 字段是你需要替换的核心，找一个真实可用的 RSS 地址，先用浏览器访问确认返回的是 XML 再填进去。
3.3 启动采集与网页服务，验证全链路
采集逻辑放在 fetcher/rss.py 里，核心代码不需要太长，关键是把字段兜底做干净。下面这段是模板里实际用的解析逻辑：
# fetcher/rss.py import feedparser import requests def fetch_feed(source): # 先手动请求，拿到字节流后交给 feedparser 解析 resp = requests.get(source["url"], timeout=15, headers={ "User-Agent": "Mozilla/5.0 (Personal News Template)" }) resp.raise_for_status() feed = feedparser.parse(resp.content) for entry in feed.entries: # 各源字段不统一，逐项兜底，保证入库数据不为空 title = entry.get("title") or "无标题" link = entry.get("link") or "" summary = entry.get("summary") or entry.get("description") or "" published = entry.get("published") or entry.get("updated") or "" yield { "source": source["name"], "category": source["category"], "title": title.strip(), "link": link.strip(), "summary": summary.strip().replace("\n", " "), "published": published, }逻辑说明：先用 requests 拿到原始字节，而不是直接让 feedparser 自己发请求，是为了能控制编码处理，这在面对非 UTF-8 源站时是救命操作。entry.get 的链式兜底确保不同 RSS 格式的字段差异不影响入库。published 字段先用原始字符串存着，展示层再格式化，避免在采集层做危险的时间解析。
参数说明：timeout=15 表示单个源最多等 15 秒，超时就抛异常，避免某个死链拖住整个采集循环。User-Agent 里的模板名是为了让源站知道这是一次正常的个人采集请求。
主应用 app.py 只负责两件事：启动时触发一次全量采集，然后提供 Web 页面。启动命令如下：
python app.py启动后浏览器访问http://127.0.0.1:5000，能看到新闻列表就说明全链路通了。如果列表为空，先别急着怀疑模板，用sqlite3 data/news.db命令行看一眼 articles 表有没有数据，八成是源地址填错了或者源站拒绝了请求。
4. 让模板更像你的产品：四个必改参数与前端定制
4.1 站点名称、分类、刷新间隔与分页大小
模板跑起来之后，第一件事不是改代码，而是把这四个参数按自己的需求调好。它们分别控制站点的身份、内容组织、更新节奏和页面密度。
| 参数 | 所在位置 | 默认值 | 建议调整 |
|---|---|---|---|
| SITE_NAME | config.py | 我的新闻站 | 改成自己习惯的名字 |
| NEWS_SOURCES | config.py | 两条示例源 | 替换成真实订阅源 |
| REFRESH_INTERVAL | config.py | 30 | 依据源更新频率调整 |
| PAGE_SIZE | config.py | 20 | 屏幕大可加到 50 |
这个表其实说明了一件事：模板的定制入口是配置而不是代码。新手拿到模板最容易犯的错是直接去改 HTML 里的标题，结果下次采集一跑，后端又把数据库里的 SITE_NAME 渲染回页面，白改一场。所有应该改成自己内容的地方，我都集中在 config.py 里，这是模板设计的核心约定。
SITE_NAME 影响的是页面顶栏和浏览器标签页标题，它在模板里的位置是<title>{{ site_name }}</title>。NEWS_SOURCES 决定你能看到什么内容，建议先保留一条示例源把链路跑通，确认没问题了再一次性填入全部源。REFRESH_INTERVAL 的调整要看源站的实际更新规律，有的站一天只更新两次，设成 10 分钟就是纯浪费。PAGE_SIZE 纯粹是阅读偏好，设太大会让页面加载变慢，个人站没必要一页显示上百条。
4.2 用模板字符串重写新闻列表，让页面响应式
模板自带的前端页面是一个简单的上下滚动列表，但我在实际使用时很快发现，列表写死在 HTML 里的方式扩展性太差。JavaScript 里的模板字符串（反引号加${}插值）更适合做新闻卡片的动态渲染。改造思路是让后端返回 JSON 数据，前端用模板字符串逐条生成卡片。
// static/app.js async function loadNews() { const resp = await fetch('/api/news?limit=20'); const items = await resp.json(); const container = document.getElementById('news-list'); container.innerHTML = items.map(buildCard).join(''); } function buildCard(item) { // 模板字符串中直接嵌入变量，比字符串拼接可读性好得多 return ` <article class="news-card">function escapeHtml(text) { return text.replace(/&/g, '&').replace(/</g, '<').replace(/>/g, '>'); }在 buildCard 里对 title、summary 调用 escapeHtml 再插入模板字符串。这个习惯在后面给页面加分类筛选、搜索功能时同样适用，属于写一次受益很久的防翻车手段。
5. 个人新闻站避坑指南：五个让我翻过车的真实问题
5.1 中文乱码：源站编码不一致
现象：采集下来的新闻标题在页面上一半正常一半变成 "锟斤拷" 或 "�" 这类乱码。
原因：源站返回的 Content-Type 里写着 charset=gb2312，但 feedparser 默认按 UTF-8 解析，或者源站根本没声明 charset，双方对不上。这个问题在我加了较多国内源之后集中爆发。
解决：采集时不让 feedparser 直接请求，改为先用 requests 拿到响应，读resp.encoding或者从 headers 里取 charset，然后手动转成 UTF-8 再喂给 feedparser。如果 resp.apparent_encoding 和声明的编码不一致，以后者为准，前者经常猜错。改完这处之后，我再也没被乱码问题折磨过。
5.2 重复新闻刷屏：缺一层标题去重
现象：同一篇新闻在首页出现了三次，分别来自三个不同的源，链接不同但标题几乎一样。
原因：link 字段的唯一约束只拦截了完全相同的 URL，但不同源转载时各自生成了不同的链接，数据库层面根本判断不出来。
解决：入库前对标题做归一化处理：去掉首尾空格、把全角标点转半角、统一大小写，然后取 SHA256 哈希存进一个单独字段并加唯一索引。这样哪怕标题里只差一个空格也能识别为重复。
5.3 定时任务“假死”：cron 和环境变量
现象：手动执行采集脚本没问题，一部署到定时任务里就完全不跑，日志里也什么都没有。
原因：cron 运行时的 PATH 环境变量里没有 Python 解释器的路径，脚本里的 python 命令解析失败。我曾在某台设备上栽在这一步，查了半天才发现是环境变量问题。
解决：定时任务的命令里全部写绝对路径，先cd到项目目录再执行，并把日志重定向到文件。比如cd /home/user/news-template && /home/user/news-template/.venv/bin/python fetch.py >> /home/user/news-template/logs/fetch.log 2>&1。如果有报错，日志文件里总能找到线索，这是定时任务排查的第一步。
5.4 抓取频率太高被封：频率控制与重试
现象：某个源连续报 403 Forbidden，浏览器能正常访问，采集脚本却被拒绝。
原因：默认 User-Agent 被源站识别为爬虫，或者短时间请求太密集触发了风控。我还踩过另一个坑：请求失败后没有设置退避时间，脚本立刻重试，反而加剧了问题。
解决：每个源设置独立的 User-Agent，在 requests 的 headers 里带上一个正常的浏览器标识再加模板名。采集循环里对失败源做指数退避，第一次失败等 30 秒重试，第二次等 5 分钟，第三次直接跳过本轮。同时把 REFRESH_INTERVAL 调到 30 分钟以上。有些源明确在 robots 里禁止采集的，别犹豫，直接从订阅列表里删掉。
5.5 手机端排版碎裂：模板缺响应式适配
现象：电脑上页面一切正常，手机浏览器打开后字体撑满屏幕、卡片挤成一列、导航栏被截断。
原因：模板的 head 里没有声明 viewport，浏览器按桌面宽度渲染后缩放，所有的 px 硬编码变成了灾难。新闻列表是信息密集场景，这个问题几乎必然出现。
解决：在模板的<head>最前面加<meta name="viewport" content="width=device-width, initial-scale=1">，并把容器宽度改成百分比或 max-width 限制。对卡片列表用 CSS 的网格布局或弹性布局，在窄屏下自动变成单列。改完之后用浏览器开发者工具的手机模拟模式快速验证一遍，比反复用真机刷新高效得多。
6. 从“能看”到“自动整理”：给新闻站加关键词标签与摘要
跑通模板之后，最值得做的一件事是给新闻自动生成关键词和一句话摘要，让首页从“信息堆”升级成“可扫读的信息流”。我实现这套功能时没有引入重量级算法，而是用分词加词频统计，数据量小的时候效果足够好。
# fetcher/tags.py from collections import Counter STOPWORDS = {"我们", "你们", "一个", "这个", "那个", "就是", "可以"} def extract_tags(text, max_tags=3): # 简单分词：先按常见分隔符拆，再过滤停用词和过短的词 words = [w for w in text.split() if len(w) > 1 and w not in STOPWORDS] # 英文场景可按空格分；中文场景建议替换为分词库处理 counter = Counter(words) return [word for word, _ in counter.most_common(max_tags)]逻辑说明：这个函数先把文本按空格拆词，过滤掉停用词和单字词，再用 Counter 统计词频，最后取出现次数最多的前三个词当标签。对英文内容这段代码直接可用，对中文内容需要先做分词，常见做法是引入中文分词库。调用时机放在采集入库前，给每条新闻生成标签字段，页面渲染时把标签显示在卡片底部。
参数说明：STOPWORDS 这个集合需要按自己的内容领域慢慢积累，我一般每跑一段时间就往里加几个高频词。max_tags=3 对个人站是恰到好处的数量，太多会让卡片显得杂乱。提取标签只在入库时执行一次，不会增加页面访问的开销。
关键词有了之后，摘要也就顺理成章。如果源站没有提供 summary，我一般取正文前 80 个字符当作摘要，有 summary 就直接清洗后使用。这一步的代码改动很小，但它带来的阅读效率提升非常明显——我很多次靠标签快速跳过不感兴趣的新闻，省下来的时间远超写这套逻辑花费的功夫。
走到这一步，你的个人新闻收集网站已经不只是“能看”的模板，而是一个有自己整理逻辑的信息工具了。这个方向我从一开始的纯收藏夹，一路改到现在的样子，最大的教训是：别在模板上堆功能，而是把采集、去重、编码这三件基础事做扎实，页面自然会好用。希望帮到你。
本文还有配套的精品资源，点击获取
=-4πδ：狄拉克δ函数与点电荷的数学本质)
