企业官网建设流程全解析

玩群晖NAS的人应该都有过这样的经历：DSM装完以后，套件中心里躺着一个叫Web Station的套件，很多人看了一眼名字就划走了，觉得这是搞Web开发才会用到的东西。我自己一度也是这么想的，直到有一天受够了浏览器里收藏夹越积越乱、换了设备就找不着链接的麻烦，才重新注意到它。结果花了一个晚上，用Web Station从零搭起了一个完全属于我自己的个人静态导航站，用到现在快两年了，稳定得几乎忘了它的存在。

这篇内容就围绕这个事情展开，把整个搭建过程拆开揉碎讲清楚：为什么选Web Station而不是Docker，虚拟主机到底怎么配，静态导航页的代码结构怎么组织，以及内网外网访问、HTTPS配置、日常维护里那些容易踩的坑。不管你是第一次接触Web Station的新手，还是已经在用NAS但是没认真折腾过静态网站的玩家，看完之后应该都能自己动手搭一个能用的导航站出来。

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

1.1 为什么偏偏用Web Station搭静态导航站

先回答一个很实际的问题：搭个导航页而已，方法多的是，为什么要用Web Station？

我当时对比过几条路线。第一是直接在本地浏览器里用收藏夹，这个最省事，但换电脑、换浏览器、用手机的时候就全乱了，而且收藏夹一多基本等于没有。第二是装第三方导航套件，比如Homepage、Dashy这类，功能确实强大，但很多依赖Docker运行，对NAS的性能有一定要求，配置起来也更重。第三就是Web Station加纯静态页面，这也是我最终选定的方案。

Web Station本质上是群晖把Nginx或Apache等Web服务器封装成的一个套件，它让用户不用SSH进系统敲命令，在图形界面里就能完成网站目录、端口、PHP版本等配置。对于静态导航站这种需求，它天然契合：我们的页面只是HTML、CSS、JavaScript文件，不需要PHP和数据库，这意味着响应速度快、占用资源极低，哪怕在J系列这种低端NAS上跑也毫无压力。

还有一个让我坚定选择Web Station的原因：可维护性。导航站的本质是“数据的组织与展示”，而纯静态站的数据可以独立拆成一个JSON文件，我只需要维护这个文件就行。增删链接不用进后台、不用连数据库，在电脑上改完文件传上去，刷新页面就生效，整个流程非常丝滑。

1.2 静态导航站到底需要哪些核心能力

很多人以为导航站就是把一堆链接堆在页面上，其实真正用起来才知道，能让日常使用效率提升的导航站至少要具备以下几点。

分类管理。我个人的链接有好几种类型，工作用的协同办公地址、开发用的服务器面板、追剧看电影的资源站、买NAS配件逛的论坛，混在一起根本没眼看，必须按类目隔开。

快速检索。这个太重要了。当导航站里存了上百个链接以后，靠鼠标翻分类已经很低效。敲键盘就能过滤出想要的站点，这个体验和浏览器地址栏直接输域名已经很接近，但胜在能帮你想起某个记不清完整域名的网站。

高频优先。每天都用的链接，比如NAS管理后台、路由器的管理页，应该排在显眼的位置，不用每次都在分类里翻找。这个可以通过简单的访问计数排序来实现。

多端适配。导航站除了在电脑上要用，手机浏览器也得能看。布局不能只在宽屏下好看，窄屏下也要能浏览。这块对CSS的响应式能力是个小考验。

整体设计思路就是“轻量、快、不折腾”。Web Station负责把网页文件发布出去，JavaScript负责读取JSON数据并渲染出导航页面，数据与展示分离，后续的每一次更新成本都被压到最低。

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

2.1 环境准备：DSM套件安装的微妙之处

在DSM里安装Web Station本身很简单，打开套件中心搜索就能装。但你如果直接点安装，后面可能会遇到问题。我建议装的时候顺手把下面这几个组件也一并勾选安装：Web Station、Apache HTTP Server 2.4、Nginx、PHP 8.2（或当前主流版本）。

之所以连PHP也带上，虽然静态站用不到，但Web Station的“脚本语言设置”里如果没有任何PHP版本，有些虚拟主机配置会提示不完整。哪怕页面全是静态的，也建议保留一个PHP版本在那里，避免后续加个小工具还得回头补装。

另外，DSM版本不同，Web Station的界面布局会有些差异。我一开始用的是DSM 6.2，后来升级到DSM 7.2，最大的变化是DSM 7以后，Web Station的后端服务器默认是Nginx，配置入口也重新组织了。升级到DSM 7的时候，原有的虚拟主机配置会自动迁移，如果你是从旧版本升上来的，记得去检查一遍端口和文档根目录有没有变化。

提示：安装套件的顺序建议是先装Web Station，再让它自动关联Apache和Nginx，最后再装PHP。手动逐个安装也不是不行，但容易出现套件之间关联状态识别不准确的问题。

2.2 虚拟主机参数配置：端口、根目录、后端服务器

安装完成后，打开Web Station主界面，左侧菜单里找到“网页服务门户”，然后点击“新增”——这一部就是创建虚拟主机。这里有几个参数需要重点说。

门户类型选择“基于端口”。如果你只有一个站点，用基于端口的方式最简单方便，直接分配一个独立端口给导航站。基于名称的虚拟主机需要配置域名解析，适合有多站点时使用，新手阶段没必要为这个增加复杂度。

HTTP后端服务器在这里我选的是Nginx。相比Apache，Nginx处理静态文件的效率更高、内存占用更小，这在高并发下载静态资源时差距很明显。不过对于个人导航站来说，两者其实都绰绰有余，选Nginx是出于更“合理”的配置习惯。

文档根目录是需要额外留意的关键点。Web默认的路径是/web，这个目录在DSM的文件管理器里能看到，不需要额外权限配置。我建议为导航站单独建一个子目录，路径类似/web/nav或者/web/startpage。这样做的目的是把导航站和其他可能发布的Web内容隔离，升级文件或备份的时候不会互相影响。

这里还有个不起眼但容易出问题的地方：Web Station新建虚拟主机时，有一个“HTTP后端服务器”的下拉选项，很多教程会让你选“Apache”，但实测下来“Nginx”在静态页面场景下的响应速度和稳定性都更好。建议直接选Nginx。

2.3 文件上传与目录权限管理的坑

创建好虚拟主机之后，把写好的站点文件传到刚才设置的文档根目录就行。传文件的方式有很多种，最简单的是用DSM的File Station网页上传。但如果你要经常更新导航数据文件，网页上传效率太低，我强烈建议同时打开群晖的WebDAV服务或SMB共享，直接把NAS的web/nav目录映射到本地电脑，改完文件保存即上传，非常方便。

说到权限这块，有一个我踩过印象很深的坑：Web Station在DSM 7里默认跑在一个独立的系统账户下，如果你的页面文件是通过SMB拷贝进去的，文件属主可能是你的管理员账户，这通常没问题。但如果你设置了过严的目录权限，Web服务器可能没有读取权限，浏览器访问时直接报403 Forbidden。

解决办法是检查文档根目录及所有上级目录的读取权限，确保Web Station使用的系统用户组能读。在File Station里右键文件夹，进入“属性→权限”，确认勾选了正确的读取权限就行。这个过程很反直觉，因为文件明明存在，但Web服务器读不到，初学者很容易卡在这里。

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

3.1 导航站文件结构与数据组织

整个导航站的代码结构非常简洁，我在服务器上维护的文件只有三四个：

/web/nav/ ├── index.html # 页面骨架 ├── style.css # 样式 ├── app.js # 渲染与交互逻辑 └── data/ └── sites.json # 导航数据，纯JSON格式

有人可能会问，为什么不直接用JavaScript把数据写死在app.js里？这个问题的答案是“维护成本”。把数据单独放一个JSON文件，意味着改导航站内容的时候只需要动一个文件，永远不会因为手误动到渲染逻辑。也方便以后写脚本自动化维护这个清单。

下面这个sites.json就是一个典型的结构，每个分类对应一个数组，数组里的每个对象代表一个网站链接：

{ "categories": [ { "name": "常用工具", "icon": "tools", "links": [ { "title": "NAS管理后台", "url": "http://192.168.1.100:5000", "description": "群晖DSM管理页面", "frequency": 0 }, { "title": "路由器管理", "url": "http://192.168.1.1", "description": "家庭网络设备后台", "frequency": 0 } ] }, { "name": "开发资源", "icon": "dev", "links": [ { "title": "GitHub", "url": "https://github.com", "description": "代码托管与开源社区", "frequency": 0 } ] } ] }

frequency字段就是用来记录访问次数的，后面在渲染的时候按它排序，用得多的链接自动排到前面。

结构上我只分了三级：分类、链接、链接属性。再复杂就没有必要了，导航站的核心是“快”，不是“重”。

3.2 页面骨架与样式实现

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="nav-header"> <input type="search" id="searchInput" placeholder="输入关键词快速过滤站点..."> </header> <div class="nav-container"> <aside class="nav-sidebar" id="categoryList"></aside> <main class="nav-content" id="linkGrid"></main> </div> <script src="data/sites.json" type="application/json" id="siteData"></script> <script src="app.js"></script> </body> </html>

这里有一个关于加载JSON的小细节值得说明：<script>标签直接加载JSON文件时，文件内容会被当作JavaScript解析，其中的中文引号或特殊字符可能会引发报错。为了绕开这个问题，我在app.js里用的是fetch异步请求，而不是传统的外部JSON引用。上面示例里保留这个标签是为了让你看到一种常见写法，但在实际部署时，我会建议删掉这个script标签，改用fetch('data/sites.json')拉取数据。

样式方面，我的设计原则是“少即是多”。底色用了低饱和度的灰色，卡片用白色背景加细阴影，在深色环境下看久了也不会觉得刺眼。栅格布局用CSS Grid实现，根据屏幕宽度自动调整每行卡片的数量：

.link-grid { display: grid; grid-template-columns: repeat(auto-fill, minmax(220px, 1fr)); gap: 16px; padding: 16px; } .card { background: #ffffff; border-radius: 8px; padding: 16px; box-shadow: 0 1px 4px rgba(0,0,0,0.08); transition: transform 0.15s ease, box-shadow 0.15s ease; } .card:hover { transform: translateY(-2px); box-shadow: 0 4px 12px rgba(0,0,0,0.12); }

这套样式用下来给人的感觉就是“干净”，页面加载时几乎没有视觉噪音，信息层级靠间距和阴影区分，不靠花哨的配色。

3.3 JavaScript渲染逻辑与搜索过滤

app.js是整个导航站的大脑，负责把JSON数据渲染成页面结构，同时处理搜索关键词的实时过滤。核心函数有两个：renderAll()负责完整渲染，filterSites(keyword)负责搜索结果过滤。

async function loadSiteData() { const res = await fetch('data/sites.json'); if (!res.ok) { console.error('加载站点数据失败：', res.status); return; } const data = await res.json(); window.siteData = data; renderAll(data); } function renderAll(data) { const sidebar = document.getElementById('categoryList'); const grid = document.getElementById('linkGrid'); sidebar.innerHTML = ''; grid.innerHTML = ''; data.categories.forEach((category, index) => { // 侧边栏分类名 const catBtn = document.createElement('div'); catBtn.className = 'category-item'; catBtn.textContent = category.name; catBtn.dataset.index = index; catBtn.addEventListener('click', () => showCategory(index)); sidebar.appendChild(catBtn); // 渲染该分类下的链接卡片 const section = document.createElement('section'); section.className = 'link-section'; section.dataset.categoryIndex = index; const h2 = document.createElement('h2'); h2.textContent = category.name; section.appendChild(h2); const cardGrid = document.createElement('div'); cardGrid.className = 'link-grid'; // 按访问次数降序排序，访问多的排前面 const sortedLinks = [...category.links].sort((a, b) => b.frequency - a.frequency); sortedLinks.forEach(link => { const card = document.createElement('a'); card.className = 'card'; card.href = link.url; card.target = '_blank'; card.rel = 'noopener noreferrer'; card.innerHTML = ` <div class="card-title">${link.title}</div> <div class="card-desc">${link.description}</div> `; card.addEventListener('click', () => recordClick(link)); cardGrid.appendChild(card); }); section.appendChild(cardGrid); grid.appendChild(section); }); }

这里我给每个链接卡片绑定了click事件，点击时调用recordClick把frequency加一。由于frequency是存在本地浏览器里的，所以这个计数不需要服务端参与，实现成本几乎为零。

搜索过滤的逻辑也很直白，监听输入框的input事件，当用户输入关键词时，把所有分类里“标题或描述包含关键词”的链接筛出来重新渲染：

document.getElementById('searchInput').addEventListener('input', function(e) { const keyword = e.target.value.trim().toLowerCase(); if (!keyword) { renderAll(window.siteData); return; } const filtered = { categories: [] }; window.siteData.categories.forEach(category => { const matchedLinks = category.links.filter(link => link.title.toLowerCase().includes(keyword) || link.description.toLowerCase().includes(keyword) || link.url.toLowerCase().includes(keyword) ); if (matchedLinks.length > 0) { filtered.categories.push({ ...category, links: matchedLinks }); } }); renderAll(filtered); });

这套逻辑的好处是“每次渲染都是全量渲染”，数据量不大时性能完全没问题，代码复杂度却因为这个简单粗暴的方案直线下降，不需要做增量更新的状态管理。

3.4 访问计数与高频置顶的实现细节

记录访问频率时，我用的是localStorage，这比Cookie更可靠，容量更大，也不会每次请求都往服务器发。

function recordClick(link) { const key = `nav_${link.url}`; let count = parseInt(localStorage.getItem(key) || '0', 10); localStorage.setItem(key, (count + 1).toString()); link.frequency = count + 1; }

实际渲染时，每条链接的frequency初始值从JSON里读，点击后在本地叠加。这样就算换了一台电脑，由于初始值还在JSON里，页面依旧会保持合理的排序。本地的点击数据相当于在初始权重之上做了一个个性化调整，两不耽误。

这个方案在数据量不大的情况下非常稳。我的导航站里现在有大概150个链接，每次排序顶多计算几百次，浏览器执行起来根本感知不到耗时。

注意：在用fetch加载sites.json时，如果你在本地直接用file://协议打开HTML调试，会碰到跨域拦截问题。解决办法是在NAS上用Web Station访问，或者本地临时起一个HTTP服务（比如Python的python3 -m http.server）再调试。

4. 内网访问、外网访问与HTTPS配置

4.1 局域网设备访问导航站

做完了页面，第一波验证就是局域网访问。虚拟主机配置好之后，在浏览器里输入http://NAS的IP地址:端口号就能看到导航站。比如NAS的局域网IP是192.168.1.100，设置的端口是8080，那地址就是http://192.168.1.100:8080。

这里有一个细节：DSM自己的登录端口默认是5000/5001，导航站要另选一个不冲突的端口。我当时选的8080，顺手在路由器里做了固定IP绑定，这样NAS的IP不会因为DHCP租约过期而变化，导航页的地址也就能一直稳定使用。

如果想把导航站设成路由器DHCP给每台设备发DNS时自动弹出的默认页面，可以更进一步把网关地址的某个端口映射到导航站上，但这需要路由器支持，操作复杂度高一些，我目前没做这个，个人导航站还没有重要到要抢占首页的程度。

4.2 外网访问与群晖DDNS方案

人在外面的时候，也想访问家里的导航站。群晖原生提供了DDNS服务，在控制面板里开启就行，它会把一个群晖分配的域名动态解析到你家的公网IP上。只要路由器做了端口转发，把外网的一个端口转发到NAS的8080，就能通过域名:端口的方式从外网访问导航站。

端口转发的配置在路由器后台，需要做一步“外部端口到内部端口”的映射。这里有个实际操作经验：外部端口尽量不要用80和8080这类常见端口，很多运营商对家用宽带的这些端口有限制，直接转发出去大概率不通。我当时给外网访问用的是18080这种高位端口，从家里出去基本没碰到问题。

注意：如果你没有公网IP，而是属于运营商分配的私网IP环境，那么群晖DDNS方案会失效。这种情况下就需要借助内网穿透工具来实现外网访问。内网穿透的选型属于另一个话题，导航站本身不需要为此做额外改动，只需要穿透工具把流量转发到NAS的8080端口就行。

4.3 HTTPS证书申请与强制跳转

现在浏览器对HTTP站点越来越不友好，尤其是有密码输入、涉及隐私Cookie的页面，不带HTTPS的时候浏览器会直接提示“不安全”。导航站虽然没有敏感数据，但地址栏上挂个“不安全”总归难看，而且有HTTPS之后，在外网访问时会少很多兼容性问题。

群晖的控制面板里自带“证书”管理功能，可以请求Let's Encrypt的免费证书，操作非常简单。

申请证书时，需要域名已经通过DDNS解析到NAS当前公网IP，并且80端口（或443端口）能从外网访问到NAS。群晖在申请证书时会在验证阶段临时起一个HTTP服务来响应验证请求。申请到证书之后，再把虚拟主机配置里的“启用HSTS”“启用HTTP/2”打开，然后设置一个HTTP到HTTPS的跳转规则。

群晖Web Station上实现HTTP到HTTPS跳转有多种方式，最简单的做法是在“门户设置”里把HTTP端口设置成跳转到HTTPS端口。有些版本的Web Station界面甚至可以直接在“网页服务门户”里给虚拟主机指定证书。实测下来最稳妥的做法还是：申请证书后，在虚拟主机的编辑页面里，把证书绑定到导航站门户，然后再到“门户设置→高级设置”里启用“自动从HTTP重定向到HTTPS”。

这套配置完成之后，访问http://域名:18080会自动跳到https://域名:18443。全站HTTPS加密，浏览器地址栏的小锁也回来了，心理上舒服很多。

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

5.1 页面打不开：权限、端口与防火墙

导航站搭建初期遇到最多的一类问题就是“浏览器访问不了”。

第一步排查目标端口。在NAS本机访问http://localhost:8080，如果能打开，说明Web Station本身没问题，问题在网络层。此时检查路由器的端口转发和NAS的防火墙。群晖DSM默认自带防火墙功能，如果你之前手动开过防火墙并设置了规则，放行了5000端口却没放行8080，那么内网的其他设备也访问不了。

第二步确认目录权限。如果浏览器访问时出现403 Forbidden，大概率是Web服务器没有文档根目录的读取权限。这个问题我在前文提到过，排查方法是在File Station里看看文件是不是可读。

第三步检查进程状态。Web Station的“网页服务门户”界面里可以看到每个虚拟主机的状态，如果显示“异常”或者“已停止”，点进去看错误日志，多半有详细的报错原因。我最常遇到的错误日志是端口被占用，这通常是因为别的套件或Docker容器先占用了同一个端口。

5.2 样式加载不出来或者页面纯文本

如果页面显示了HTML，但没有任何样式，打开浏览器开发者工具（F12）切到Network面板，大概率能看到style.css请求的状态码是404或403。

404的原因是路径写错了。我建虚拟主机时把文档根目录设成了/web/nav，但HTML里链接的是/style.css，而不是./style.css，那么请求的完整路径就变成了/style.css，自然找不到文件。解决办法是尽量在HTML里使用相对路径，比如./style.css、./app.js，这样页面在哪个子目录下都能正确加载。

403的原因则回到了权限问题，和前面说的目录不可读是同一个根因。

这个坑对新手来说特别容易踩，因为本地用编辑器预览HTML时，相对路径和绝对路径的效果是相同的，一旦到了服务器目录结构下才暴露问题。

5.3 内网能访问、外网总超时

这类问题排查思路比我刚才说的要复杂一些。先确认外网地址的端口是否通。最简单的方法是手机流量开热点，用流量访问http://域名:端口，这一步能快速判断当前网络环境是不是有公网IP的“假外网”。如果手机流量访问不了，而家里宽带访问正常，基本可以确定是端口转发或运营商封锁的问题。

下一步检查NAS上是否同时存在多条端口转发规则。很多时候用户调整过路由器配置，旧的转发规则没清理，新规则又加了上去，两条规则冲突导致转发失败。这个要进路由器后台把相关规则全部理一遍。

还有一个很容易被忽略的点：群晖自带了一个“路由器配置”功能（在控制面板→外部访问里），如果NAS没有通过UPnP自动注册过端口转发规则，而路由器又开启了AP隔离或访客网络隔离，那么即使端口规则存在，从外网来的流量也可能无法到达NAS。这就需要在路由器上关闭AP隔离，或者把NAS单独设成固定IP并加入例外列表。

5.4 导航站数据备份与日常维护

导航站建好之后，真正的长期成本在数据维护。我的更新习惯是每周末花几分钟过一遍data/sites.json，把失效的链接删掉，把新发现的网站加进去。

数据备份方面，web/nav这个目录包含全部代码和数据，加上DSM自带的Hyper Backup，把它们纳入备份任务就行。NAS本身还有快照功能，为web目录开启快照，误删数据也能随时找回。

提示：如果某天你发现导航站页面打不开了，第一件事不是重装Web Station，而是检查NAS存储空间是不是满了。我遇到过两次类似情况，都是因为快照占满了存储池，导致套件写入异常，页面直接白屏。

最后再分享一个让维护更省力的小技巧

我个人体验下来，这套“Web Station + 静态JSON”的方案最大的优势不是搭建过程有多快，而是日常维护极其轻量。浏览器收藏夹越堆越乱的问题彻底消失了，所有链接都以文本格式存在自己手里，想迁移就复制走，想批量改就写个脚本处理，没有任何厂商绑定。

如果你把导航站搭起来了，建议后面可以试着加上一个新功能：直接把sites.json放进一个Git仓库，每次修改后提交一次，这样每一次增删链接都有历史记录，哪次改坏了也能一键回滚。和群晖的Drive套件配合使用，还能实现多设备同步维护，在电脑上编辑完自动同步到NAS，再从手机浏览器打开就是最新版。这个体验用下来非常舒服，值得试一试。