企业官网建设流程全解析

简介：这份PDF宣传册系统梳理智慧城市的前沿理念与实践框架，面向政府规划人员、城市建设者、相关专业学生以及对智慧生活感兴趣的读者。内容从数据驱动的城市管理切入，覆盖智能交通、智慧医疗、智慧教育、智能电网、环保监测、民生服务与新兴产业等多个维度，既有理念阐释也有场景列举，便于读者在较短时间内建立对智慧城市整体架构的认知，也能为方案撰写、科普展示提供结构清晰的素材。资源包仅含1个PDF文件，大小约30.24MB，图文排版适合直接用于行业科普、内部培训或方案路演，内容按照理念、构成与影响等模块展开，便于按需查阅重点章节。目前已有315人浏览学习，适合作为洞察未来城市发展趋势、了解智慧城市落地方向的入门参考资料。

1. 为什么"智慧城市宣传册.pdf"值得当成工程来做

收到一份叫"智慧城市宣传册.pdf"的交付物，大多数人会当成设计排版的结果，翻开看看版式、改改措辞就完事。但从工程视角看，这份 PDF 不是终点，而是一条生产线的输出。面向政企客户的智慧城市宣传册，要覆盖城市级业务全景、平台能力和落地指标，内容量大，还要跨部门反复修订。把文稿、数据、图表、布局全揉在一个 Word 文件里维护，越到后期越痛苦。常见做法是把素材结构化，用 HTML/CSS 做排版，再通过无头浏览器导出 PDF，最后用命令行检查页面规格与文本层。这套流程能接 Git、能进 CI，也能在一键重新成文时保持稳定。下面就从内容骨架讲到参数设置和验收命令，给你一条完整的落地路径。

2. 先搭内容骨架：智慧城市宣传册的信息架构与素材清单

一份宣传册 PDF 能不能说服人，第一关不是视觉效果，而是有没有逻辑主线。智慧城市宣传册最常见的败笔，是把几十个产品功能点平铺在里面，每页都像 PPT 截图，看完记不住你到底解决什么问题。反过来，有经验的做法是先定章节地图，让每一页对应一个明确的决策问题，再往里面填内容。

2.1 智慧城市宣传册的固定模块：一张能复用的章节地图

我一般会把宣传册拆成六个固定模块。下面这张表是长期迭代后形成的默认结构，适用于数字政府、智慧园区、智慧交通这类面向政企客户的智慧城市解决方案。模块顺序有讲究：先讲背景和总览，让读者建立坐标系；再讲能力和方案，让读者找到自己的场景；最后用案例与合作模式收尾，降低商务沟通阻力。

架构图和能力清单是最容易被低估的两块。很多团队只画一张拓扑图就带过，客户拿到手依然找不到"这件事跟我的关系"。架构图至少要拆成云底座、数据中台、应用使能、行业应用四层，每一层对应具体的产品名或交付物名称，不能只给抽象概念。案例部分则要带上可验证的指标，比如"1200+ 项高频事项全程网办"就比"效率大幅提升"可信得多。

2.2 用 YAML 组织文案数据：内容与版式解耦的第一步

内容架构定了之后，我会把文案素材先变成结构化数据，而不是让人直接在排版软件里打字。这样做有两个直接好处：宣传册里的数据、产品名、案例指标从同一个数据源读出，不会出现正文和图表不一致；换版式时也不需要重新录入内容。以智慧政务板块为例，素材文件可以组织成这样：

sections: - id: smart-government title: "智慧政务：一网通办的业务底座" headline_key: "政务协同效率提升" statistics: - value: "1200+" unit: "项" label: "高频事项实现全程网办" - value: "30%" unit: "" label: "窗口平均排队时间压缩" capabilities: - "统一身份认证与电子证照库" - "事件分拨与跨部门协同流程引擎" - "数据驾驶舱与领导决策看板"

字段含义需要注意三点：statistics[].value里的数字和单位拆开存，避免翻译或换版式时把"1200+"改成"1,200+"导致正则替换失败；capabilities是宣传册里最容易被复制到别处的内容，建议再维护一条同义名检查，防止产品改名后宣传册和官网各说各话；headline_key对应文案库里的多语言条目，如果客户要求出双语版，就能用同一套 YAML 渲染两份 PDF。

2.3 地图、大屏截图与字体授权：素材清单和版权留档

内容结构搭好之后，最后一个容易在交付前爆雷的是素材质量。智慧城市宣传册里最常见的地图素材，如果来自测绘部门的公开成果，需要保留数据来源说明，避免交付后被质疑合规性。建筑渲染图至少要 300dpi，在 A4 页面上对应约 2480x3508 像素；网页截图只适合做功能示意，拉伸到整页就会糊。我通常在项目目录里维护一个assets/manifest.json，记录每个文件的用途、源文件路径、版权状态和最终压缩参数，追到具体某一页某张图的来路时不用翻聊天记录。

实操经验是：源图保留高品质大图用于印刷，HTML 渲染用 sRGB 压缩副本。两种颜色空间之间的转换过程做好留档，避免印刷厂追色时双方对不上。字体也一样，造字工房或方正字库的商用授权要提前确认，等 PDF 都出了才发现字体没授权，替换成本比购买授权高得多。

3. 用 HTML/CSS 生成智慧城市宣传册 PDF：选型与最小方案

这一章进入技术主干。选定 HTML/CSS 加无头浏览器生成宣传册 PDF，是因为它有三个其他方案给不了的特性：与内容数据解耦、版式可编程、能接入 CI 构建。用 LaTeX 或 Word VBA 也能做，但要么版面定制成本过高，要么无法稳定处理中文字体和复杂的图文混排。

3.1 为什么抛弃 LaTeX 和 Word：一张选型对照表

LaTeX 在学术排版里很强，但在智慧城市宣传册这类强视觉材料上反而吃力。自由设计的封面、大图裁切、圆角卡片、投影效果，在 LaTeX 里实现成本远高于 CSS；中文字体配置也比较繁琐，更不用提让非技术同事参与内容维护的难度。Word 的 VBA 能实现一部分自动化，可跨版本渲染差异很大，同一份文档在不同机器上预览，字体替换和分页位置经常变。HTML/CSS 天然支持文本流与盒模型，分页媒体模块就是专门为纸质输出设计的。

分页控制上 LaTeX 确实更强，但宣传册常见的多栏、全出血大图和圆角卡片，用 CSS 做起来效率高得多。如果要出落地页式的宣传册，HTML/CSS 是综合性价比最高的选择。

3.2 先用 Jinja2 把 YAML 渲染成 HTML 骨架

数据文件准备好之后，下一步是把 YAML 填进 HTML 骨架。我推荐用 Jinja2，因为它语法简单、和 Python 生态配合好，也方便后续接其他自动化脚本。下面是一小段模板示例：

from jinja2 import Environment, FileSystemLoader import yaml env = Environment(loader=FileSystemLoader('.')) template = env.get_template('brochure.html.j2') data = yaml.safe_load(open('data.yaml', encoding='utf-8')) html = template.render(data=data) with open('brochure.html', 'w', encoding='utf-8') as fp: fp.write(html)

这段脚本的流程是：读取当前目录下的data.yaml，加载brochure.html.j2模板，用template.render把数据传入模板，最后把完整 HTML 写到brochure.html。Jinja2 的Environment负责查找模板文件，FileSystemLoader可以指定模板目录，这里用的是当前目录。文件编码统一写成utf-8，否则中文在 Windows 环境会乱码。

3.3 Puppeteer 输出 PDF 的最小可运行脚本

HTML 生成之后，用 Puppeteer 把它渲染成 PDF。假设brochure.html已经就位，下面的脚本用 Node.js 运行：

const puppeteer = require('puppeteer'); (async () => { const browser = await puppeteer.launch({ headless: 'new', args: ['--no-sandbox', '--disable-setuid-sandbox'] }); const page = await browser.newPage(); await page.setContent(require('fs').readFileSync('./brochure.html', 'utf8'), { waitUntil: 'networkidle0' }); await page.emulateMediaType('print'); await page.pdf({ path: './智慧城市宣传册.pdf', width: '210mm', height: '297mm', displayHeaderFooter: true, headerTemplate: '<span style="color:#777;">智慧城市解决方案</span>', footerTemplate: '<span style="color:#999;">第 <span class="pageNumber"></span> 页 / 共 <span class="totalPages"></span> 页</span>', printBackground: true, margin: { top: '18mm', bottom: '18mm', left: '16mm', right: '16mm' }, pageRanges: '1-3' }); await browser.close(); })();

核心是page.pdf()的参数组合。width和height直接用物理单位而不是format: 'A4'，是因为后者在某些 Puppeteer 版本里会与自定义 margin 产生计算偏差。emulateMediaType('print')让页面应用 CSS 的@media print分支，屏蔽屏幕端的交互样式。displayHeaderFooter配合模板显示页眉页脚，页脚里的页面编码用内置的pageNumber和totalPages类名填充，不能自己写数字。

printBackground必须设成 true，否则 CSS 里的background-color和渐变在 PDF 里全部丢失，深色底导航栏会变成白底黑字。pageRanges在调试阶段建议保留，先输出前几页加快反馈节奏，定稿前删掉即可。--no-sandbox在 CI 环境基本是标配，本地 Mac 或 Windows 不需要。如果headless: 'new'报参数错误，说明 Puppeteer 版本比较老，直接改成headless: true。

3.4 分页、页眉页脚与侧边栏目录：三个必调项

上面的脚本只解决了能出 PDF 的问题，宣传册还要处理分页、页眉页脚样式和目录跳转。

CSS 分页用page-break-before或break-before控制，更推荐在每个章节容器上同时加break-inside: avoid，防止一个模块被切断：

.brochure-section { page-break-inside: avoid; break-inside: avoid; } .module-card { page-break-after: always; }

page-break-*是兼容旧引擎的写法，break-*是标准属性，两个同时写最稳妥。page-break-after: always让每个卡片独立成页，适合"一页一个方案"的格局。注意不要对所有卡片用break-inside: avoid，如果卡片高度超过一页，会造成整页空白，这个属性只加在高度可预估的容器上。

页眉页脚模板里的样式要用内联写法，它不继承正文 CSS。页脚页码默认从 1 开始，封面不想显示页脚时，制作上更省事的做法是让封面页固定page-break-after: always，接受页码从第二页开始，初稿阶段不必追求绝对精确。超过 10 页的话，侧边栏目录跳转的补写放到第 5 章讲。

提示：Puppeteer 的setContent不会自动补<meta charset="utf-8">，HTML 文件里没写的话，中文标题在 PDF 里会显示成乱码。生成 HTML 时就要在<head>里带上编码声明。

4. 智慧城市宣传册 PDF 的排版参数、打印设置与常见坑

HTML/CSS 渲染 PDF 的便利性是有代价的：你几乎能控制所有细节，但容易忽略屏幕显示和纸质输出的区别。这一章集中讲排版参数的实际取值和出错时的排查方向，重点照顾中文环境。

4.1 字号、行距与中文字体栈：印刷阅读的舒适区间

宣传册不是技术白皮书，文字密度要低。正文参数我一般这样定：字号10.5pt（中文五号），行高1.6，段落间距6pt。标题用20pt / 16pt / 13pt三档，对应章节、模块名和功能点标题，控制在三级以内。这组参数能让 A4 页面在保持信息量的同时版面透气。

body { font-family: "Source Han Sans SC", "Noto Sans CJK SC", "Microsoft YaHei", sans-serif; font-size: 10.5pt; line-height: 1.6; color: #2b2b2b; } h1 { font-size: 20pt; margin: 22pt 0 12pt; } h2 { font-size: 16pt; margin: 18pt 0 10pt; } h3 { font-size: 13pt; margin: 14pt 0 8pt; } p { margin: 6pt 0; text-align: justify; }

字体这一行值得展开。Source Han Sans SC和Noto Sans CJK SC是同一款字体在不同发行渠道下的名字，两个都写能让渲染引擎优先命中本机已有的字体。Microsoft YaHei是 Windows 系统的兜底。text-align: justify是中文排版必备，否则右侧边缘参差不齐，搭配text-justify: inter-ideograph能改善中文断行和标点挤压。

4.2 颜色模式与嵌入字体：屏幕和纸张的差异

屏幕渲染用 RGB，纸质印刷用 CMYK，这是宣传册制作里最容易产生色差的环节。如果只出电子版 PDF，用 RGB 没太大问题；要是送印刷厂，就要把品牌色在排版前转成 CMYK 近似值。HTML/CSS 不支持 CMYK 色值，常见做法是视觉设计先确定关键色的 CMYK 近似值，在 CSS 注释里记录，交付印刷时另附色值对照表。宣传册里最常见的"智慧城市蓝"，近似值是#0A5EB8，CMYK 约C89 M56 Y0 K0，但这个对应不是精确换算法，最终以印刷打样为准。

字体嵌入是另一个隐蔽问题。如果字体没有随着 PDF 打包，换个设备打开就变成方框。Puppeteer 默认会对页面实际用到的字形做子集化嵌入，不需要手工剪裁。判断字体是否嵌入，用pdffonts看一眼：

pdffonts 智慧城市宣传册.pdf

输出里字体名带subset字样说明嵌入正常；出现non-embedded标记，说明这张 PDF 引用了外部字体，换设备会出问题。还有一种情况：明明嵌入了字体，复制出来的文字却是乱码，这通常是字体子集缺少 ToUnicode 映射表，这类问题多出在自造或改造过的字体上，解决办法是换回正版标准字体。

4.3 文件大小失控的排查思路与图片压缩参数

宣传册 PDF 动辄几百 MB 是高频事故。原因集中在三个地方：图片未压缩、页面多且矢量图表密集、字体被做成全量嵌入。图片优先排查。准备阶段就把压进 PDF 的图片统一处理到合适分辨率：A4 整版 300dpi 约 2480x3507 像素，全宽跨页图 2400px 宽已经够用。Puppeteer 的page.pdf不提供图片压缩参数，压缩要放在 HTML 生成之前。用 Python 的 Pillow 库做这步很直接：

from PIL import Image from pathlib import Path raw_dir = Path('./assets/raw') out_dir = Path('./assets/compressed') out_dir.mkdir(exist_ok=True) for p in raw_dir.glob('*.jpg'): img = Image.open(p).convert('RGB') img.thumbnail((2400, 2400)) img.save(out_dir / p.name, quality=82, optimize=True)

thumbnail会等比缩放且不会放大图片，quality=82是一个比较稳的 JPEG 起点，文字边缘不会有明显振铃。图表密集的页面可以把质量提到 88 再试，但建议按"封面大图"和"内容插图"分两批设置质量档，不要所有图用同一个值。

提示：如果 HTML 里有 base64 内嵌图片，Puppeteer 会一并写进 PDF，这种图没法单独压缩，而且会显著增加文件体积。尽量用相对路径引用图片文件。

压缩后如果还需要瘦身，用 qpdf 做一次线性化：

qpdf --linearize in.pdf out.pdf

这个操作不改变画面内容，只对 PDF 的内部对象重新组织，让文件布局更紧凑，也方便在线阅读器流式加载。qpdf 之后文件还大，就要回到图片压缩环节，而不是继续找其他压缩工具硬压。

4.4 文本层检测与 OCR 兜底

智慧城市宣传册发出去以后，客户会把里面的指标复制进自己的方案里，所以文本层必须可靠。Puppeteer 渲染文字生成的 PDF 天然带文本层，但要用命令确认：

pdftotext 智慧城市宣传册.pdf - | head -80

如果输出为空或乱码，说明没有可靠文本层。有一种情况是页面用了背景图承载文字，渲染时文字被画在图上而不是 HTML 里，这样 PDF 看起来正常但无法检索。遇到这种情况，先把文字移回 HTML 再重新渲染。如果源文件确实只有扫描稿或图片稿，再用 OCR 识别并生成带文本层的 PDF，但这不是首选方案——OCR 对数字和单位容易出错，宣传册里的量化指标一旦被识别错，影响比没文本层更严重。

5. 验证产出质量与持续迭代：一份可复检的智慧城市宣传册 PDF

宣传册交付前要过三类机器检查：页面规格、文本层、内部结构。肉眼翻页解决不了打印时页边距偏差，也发现不了文字变成描边的问题。把检查整理成命令，接在生成脚本后面。

5.1 用 pdfinfo 与 pdftotext 做双层机器检查

先验证页面规格：

pdfinfo 智慧城市宣传册.pdf | grep -E "Pages|Page size"

A4 对应的 Page size 应为 595.28 x 841.89 pts。如果偏成其他数值，检查width、height与margin相加是否有偏差。这个差异在屏幕上不明显，但送印刷厂后整个版心统一偏移，裁切可能出界。页面规格不对，不要继续后面的检查，先回到生成脚本修参数。

再验证文本层和关键词命中：

for kw in "数据中台" "一网统管" "城市大脑" "数字孪生"; do echo -n "$kw: " pdftotext -q 智慧城市宣传册.pdf - | grep -o "$kw" | wc -l done

这段命令把 PDF 全文转成纯文本，统计关键词行数。命中数为 0 说明文本层缺失；命中数远低于预期，说明有部分页面的文字以图片形式存在。检查关键词时，优先选宣传册里承诺的能力词，而不是产品名——产品名可能改，但"数据中台"这类能力词必须稳定出现。

5.2 把构建与验收串进一个命令

页面规格、文本层、字体嵌入三个检查通过后，把这些步骤连同构建过程写进脚本：

#!/usr/bin/env bash set -euo pipefail jinja2 brochure.html.j2 data.yaml > brochure.html node render.js pdfinfo 智慧城市宣传册.pdf pdftotext 智慧城市宣传册.pdf - | grep -c "数据中台" pdffonts 智慧城市宣传册.pdf

set -euo pipefail让脚本在任一步失败时直接退出，避免带着坏产物继续往下走。node render.js跑的是第 3 章的 Puppeteer 脚本。后面三条命令分别检查页数尺寸、文本层和字体嵌入，输出结果一眼就能看出有没有问题。

动辄十几页的宣传册，还建议用 qpdf 的 JSON 模式补看书签结构：

qpdf --json 智慧城市宣传册.pdf | grep -i outline

如果输出为空，说明 PDF 没有侧边栏大纲。Puppeteer 的page.pdf不会自动生成完整书签，需要用 pikepdf 或类似工具打开 PDF，按章节标题补写书签条目再另存。这个后处理脚本单独维护，渲染引擎只负责版式，文档的导航结构属于语义层交付物，混在一起改会反复动版式。

最后把这些命令串进一个 npm script 或 Makefile，内容数据更新后只跑一条指令，就能拿到规格合格、文本层完整、带书签的成品。CI 里加上定时构建，素材变更后就能自动发现图片尺寸不够、文本层丢失、页数异常这三类最频繁的生产事故。宣传册从一次性交付物变成可持续维护的产品，靠的正是这一步。

本文还有配套的精品资源，点击获取