企业官网建设流程全解析

简介：面向希望用Delphi进入Web前端与跨平台应用开发的初学者和进阶开发者，这份PDF教程围绕TMS WEB Core框架展开，着力解决传统Delphi程序员转向HTML/JS应用时的概念断层与环境配置问题。内容从Web开发框架概览、Object Pascal历史与现状切入，比较IntraWEB、uniGUI与TMS WEB Core的特点，并涵盖Web基础、项目配置、自动化版本管理、Lazarus安装、渐进式Web应用、Electron/Miletus桌面应用、Pas2JS编译、RTL运行时库、调试与页面设计等模块。资源包为1个PDF文件，约3.84MB，轻量便于查阅；已有5029人学习。读者可据此建立TMS WEB Core的整体知识框架，理解100% HTML/JS应用的生成、部署与调试路径，并借助框架对比、组件技能和快速入门内容，缩短从桌面开发迁移到Web与移动端开发的摸索时间。

1. Delphi 写前端：三个框架摆上桌，先想清楚浏览器里跑的是什么

第一次被 Delphi Web前端选型卡住，不是代码写不出来，是 IntraWEB、uniGUI、TMS WEB Core 这三个名字到底差在哪。基于 TMS WEB Core 框架那条，把 Object Pascal 经 Pas2JS 转译成原生 HTML/JS，浏览器里没有二进制、没有插件，产物丢进托管目录就能跑；另两条则是服务端常驻进程替浏览器干活。这篇不讲情怀，把三条路线摊开，用组件贴合度、调试链路、部署形态、迁移成本四个指标做成表，再补几个我亲手翻过的车。写给正在纠结“用哪套写前端、老 Delphi 资产又不想全扔”的人。

2. 三条技术路线：TMS WEB Core、IntraWEB、uniGUI 各自把代码送到了哪一层

先把话撂在前头：这三者不是同类替代品，把它们放进同一张选型表里比较，前提是你得先搞清楚“浏览器最终拿到的是什么”。我见过太多团队一上来就问“哪个组件多”“哪个上手快”，问到第三个问题才想起来自己的项目到底要不要常驻服务端。顺序反了，后面全是返工。

2.1 TMS WEB Core：Pas2JS 编译出来的产物长什么样

TMS WEB Core 的地基是 Pas2JS，一个把 Object Pascal 源码转译成 JavaScript 的编译器。你在 IDE 里拖控件、写事件、挂数据源，最后生成的是 HTML、JS、CSS 加资源文件这一套静态产物，浏览器拿到的就是这些，中间没有.exe、没有 DLL、也没有一个替你渲染页面的后端进程。教程里把 RTL 运行时库、预处理器、命令行编译、实用功能性函数单独拎出来讲，不是凑篇幅——这四样东西恰好是这条链路能不能走通的关键节点：RTL 决定了哪些 Delphi 标准库函数在浏览器里能直接用、哪些需要绕道；预处理器决定了你能不能按构建目标切换代码分支；命令行编译决定了能不能接进 CI；功能性函数则是把 Pascal 习惯带到 JS 世界的黏合剂。

这个产物的形态会反过来决定后面所有事。部署是“拷文件”级别的，静态托管、对象存储、任意一家能放 HTML 的服务器都能接；调试不能只盯 IDE 断点，因为真正跑在浏览器里的是转译后的 JS，DevTools 必须进你的日常工具链；性能瓶颈大概率落在生成的 JS 体积和首屏加载上，而不是服务端 CPU。我一般会这么判断：如果这个项目的交互大部分发生在浏览器侧、后端只是提供 REST 数据，那 TMS WEB Core 的部署优势是真的能换成钱的；反过来，如果业务逻辑本身重、状态机复杂、还要跟大量既有服务端 Delphi 代码共享，那省下的部署成本很可能被多花的调试时间吃掉。

再补一个容易被忽略的点：Pas2JS 生成的是能被浏览器直接执行的代码，这意味着你的前端产物是可以被任何人打开 DevTools 阅读的。这对内部工具无所谓，但对需要保护算法细节的产品就是个硬约束，选型时最好提前想清楚。

2.2 IntraWEB 与 uniGUI：服务端替浏览器干活的那条路

IntraWEB 和 uniGUI 走的是另一条思路：服务器上跑一个常驻应用进程，浏览器发请求、服务端生成页面或者把状态推回去，本质更接近“把桌面窗体搬到浏览器里”。培训资料给 IntraWEB 的标签是实时更新能力强、定制性高，给 uniGUI 的标签是组件库覆盖面广、相对好上手。这两个标签背后是同一件事——它们的 UI 逻辑仍然活在服务端，你的 Delphi 写法基本不用改，事件处理器还是那个事件处理器，只是触发它的人从本机鼠标变成了远端浏览器。

这条路线的优势很实在：老项目迁移时 UI 代码复用度高，业务逻辑不用重写成 Pascal→JS 那一套，团队不需要重新学一遍前端思维。代价同样清楚：服务器不能停，停了页面就废；并发上来之后要算连接数、算内存、算长连接维持成本；前端交互的响应速度受网络往返影响，在弱网环境下体感差距会放大。还有一点，服务端渲染那一派在“页面要不要被搜索引擎抓到”“首屏能不能秒开”这类问题上，通常需要额外做工作，不像静态产物那样天然占优。

我一般会这么比：把这三条路线想象成三种交付方式。TMS WEB Core 是“交静态文件”，IntraWEB 和 uniGUI 是“交一个跑着的服务”。前者适合把前端当独立产物来管，后者适合把前端当服务端应用的延伸。这个判断比看组件数量表要准得多。

2.3 一份部署与调试对照表：三条路线的真实差异

把上面的判断收进一张表，比翻文档快。

提示：这张表只描述路线差异，不构成“谁更好”的结论。真实项目里往往是混合形态——新增模块用 TMS WEB Core 写，老系统保持原样，两边通过 REST 接口对接。

可执行的部分在这里：与其看表，不如做一次小对照实验。挑一个最小但完整的场景——一个登录框加一张带分页的数据表格，分别在三个框架里各搭一遍，计时记录三件事：从零到页面能跑起来花了多久、第一次改需求时改了哪些文件、部署到一台干净服务器上需要几步。这三个数字比任何评测文章都诚实。我带过的一个小组做过类似的事，结论是 TMS WEB Core 在“首次跑通”上慢一点，但在“第二次部署”上快一大截，因为产物就是文件，不用管进程。

3. 四个硬指标：组件贴合度、调试链路、部署形态、迁移成本怎么比

选型表一旦落到具体指标，讨论就不会变成站队。下面这四个维度是我这几年反复用的一套，按重要性排序，但每个项目的权重可以自己调。

3.1 组件贴合度：页面是 HTML 模板驱动还是控件拖拽驱动

先问一个很具体的问题：你的页面长得更像“一个表单”，还是更像“一篇文章”？表单型页面控件密集、布局规整，控件拖拽那一派（IntraWEB、uniGUI）匹配度高；文章型页面结构自由、需要跟设计稿对齐，HTML 模板驱动那一派（TMS WEB Core）更顺手。教程里专门讲了 TWebLabel、TWebButton、TWebEdit 这一长串控件，每个都带 HTML 模板标签、属性、事件三段说明，这不是文档啰嗦，是在告诉你：控件和 HTML 模板之间有一层映射关系，你得知道哪个控件对应哪个标签，改样式时才知道往哪下手。

我一般会这么比：把项目里最复杂的那个页面截个图，在三个框架的控件列表里找对应物，找不到的记一笔。找不齐的地方就是未来的定制开发量，这笔账比任何宣传页都准。TMS WEB Core 的好处是控件本身封装的是 HTML 元素，实在不够用时可以直接写 HTML/CSS 兜底；IntraWEB 和 uniGUI 也有各自的扩展方式，但兜底路径不同，要提前问清楚。

3.2 调试链路：IDE 断点、浏览器 DevTools 和中间那层转译

调试这件事在三条路线上完全不是一回事。TMS WEB Core 的代码最终变成 JS，IDE 断点能停，但你得清楚停在哪一层——是 Pascal 源码层，还是转译后的 JS 层。教程把 Pas2JS、RTL、预处理器、命令行编译放在一起讲，就是在给你铺这条调试链路：源码映射对不对、转译产物能不能读、预处理器分支有没有生效，这三件事决定了你排查一个线上问题要花十分钟还是半天。

服务端渲染那一派的调试路径相对短，断点打在自己的 Delphi 代码里，变量就在手边，这是它实实在在的优势。但代价是前端行为的可见性变弱——浏览器里到底发生了什么，你得靠日志和服务端状态去推。

我一般会这么比：模拟一个真实故障场景，比如“点击按钮后数据没刷新”，在三个框架里各排查一次，记录从发现到定位的时间。这个练习比读十篇入门教程都有用。血泪经验是，前端问题在服务端渲染路线里经常被误判成后端问题，绕一圈才回来。

3.3 部署形态与迁移成本：静态托管、常驻进程、老代码怎么搬

部署形态这条前面说过，这里补迁移成本。老 Delphi 资产迁移大致分三块：业务逻辑、UI 代码、第三方依赖。业务逻辑如果是纯计算、纯数据处理的单元，搬到 TMS WEB Core 里通常改动不大，因为 Pascal 语法那套东西还在；UI 代码基本要重写，因为事件模型和布局方式都变了；第三方依赖是最大的变数——依赖 Windows API、依赖本地文件、依赖本地打印的模块，在前端路线里要么找替代方案，要么留在服务端。

服务端渲染那一派在这块的优势是老 UI 代码能带着走，但也不是零成本，组件替换、样式适配、并发改造一样要花时间。我见过一个项目组以为“搬过去就能跑”，结果卡在打印和本地设备访问上，最后做成了混合架构。

一个可执行的动作：把老项目按“纯逻辑 / 依赖本地环境 / UI”三类拆一遍，估算每类的迁移工作量，再和三条路线对照。这个动作做完，选型基本就定了。

4. 跑通第一个 TMS WEB Core 页面：环境、项目设置到编译产物

理论说够了，落地。这一章按“装—配—画—编”的顺序走一遍，每一步都标出该看什么、失败时该查什么。

4.1 环境准备与项目设置里最该动的几个开关

教程里明确说了，学习这套东西只需要免费的 Delphi 社区版加 TMS WEB Core 试用版，Lazarus 也在支持范围内。安装本身没什么玄学，真正容易踩的是项目设置。新建项目时你会看到几个模板：普通 Web 应用、渐进式 Web 应用（PWA）、Electron 桌面应用、Miletus 桌面应用。这四个不是随便选的，选错了后面改起来麻烦——PWA 涉及离线缓存清单，Electron 和 Miletus 涉及额外的宿主壳，普通 Web 应用才是纯净的静态产物。

项目设置里值得盯住的几项：输出目录（决定你部署时拷哪个文件夹）、目标浏览器（影响转译时的 polyfill）、源映射开关（调试期开、发布期关）、以及自动化版本管理相关的选项。教程把“自动化版本管理”单列一节，说明它不是可选项——前端产物带缓存，版本号不对，用户拿到的可能是旧 JS。

我一般会这么配：开发期源映射开、压缩关；发布期反过来。这个习惯救过我一次，某个样式问题只在压缩后出现，靠源映射十分钟定位，没源映射得猜一晚上。

4.2 页面设计与 HTML 模板同步：实时预览怎么用才不骗自己

TMS WEB Core 的页面设计有两套逻辑在跑：一套是 IDE 里的设计器，一套是浏览器里的真实渲染。教程专门讲了绝对定位、相对定位、主题、BiDiMode 双向模式，还有“使用 HTML 模板”“自动同步 HTML 模板”“实时预览”这几节。这里的关键认知是：设计器里看到的和浏览器里看到的，不保证一致，实时预览就是用来消掉这个差距的。

HTML 模板同步这个功能很实用，但用错了会翻车。它的逻辑是你改模板，IDE 那边跟着更新，问题是双向同步时谁覆盖谁有讲究。我一般会这么做：模板改动集中在模板文件里做，控件属性改动集中在 IDE 里做，两边不交叉；真要交叉时，先提交一次版本再动手，给自己留后悔药。

4.3 命令行构建与产物检查：看清编译到底吐出了什么

图形界面点“编译”很爽，但接 CI 或者做批量构建时，命令行是绕不开的。教程里单列了“命令行编译”和“预处理器”，这两块建议早点上手。

# 命令行构建入口：把 Pascal 源码转成浏览器可执行的脚本 # -Jc 指定输出走浏览器可用的模块格式 # -Fu 追加 RTL 与框架单元的搜索路径，路径按本机安装位置改 # -o 指定落盘的 JS 文件，通常放在部署目录的 js/ 下 # 具体的编译参数名以你本机 Pas2JS 版本的项目设置为准 pas2js -Jc -Tbrowser \ -Fu"rtl" -Fu"tmswebcore" \ -o"deploy/js/main.js" src/Project1.dpr

这段脚本的重点不在参数本身，在“产物检查”这个动作。编译完之后一定要打开deploy目录看一眼：HTML 在不在、JS 体积多大、资源文件有没有漏、源映射文件是不是被误打包进去了。我见过不止一个项目上线后 404，最后一查是产物目录结构跟服务器路径对不上。把“编译完看产物”做成肌肉记忆，比任何调试技巧都省时间。

5. 避坑记录：五个翻车现场，按现象、原因、解法拆开

下面这五条都是真实踩过的，按“现象 → 原因 → 解决”写，能对号入座最好。

5.1 编译零报错，打开浏览器一片白

现象：IDE 编译通过，控制台没有红色报错，页面白屏，连布局都没出来。

原因：最常见的是入口 HTML 引用的 JS 路径不对，或者 JS 加载了但初始化代码在 DOM 就绪前就跑了。次要原因是某个单元在转译时被裁掉了，运行期才报错，而错误又被吞在异步回调里。

解决：先看 Network 面板，确认 JS 是不是 200；再看 Console 有没有被过滤掉的 warning；最后在入口处加一行最朴素的输出，确认代码真的执行到了。这三步能覆盖八成白屏。

5.2 桌面浏览器正常，移动端事件全丢

现象：Chrome 桌面版点击、输入都正常，换到手机浏览器或者 DevTools 的移动模拟，按钮没反应。

原因：触摸事件和鼠标事件不是一套模型。某些控件默认绑的是鼠标事件，移动端不触发；另一部分是 CSS 层面的点击区域被遮挡，看着能点其实点不到。

解决：先用 DevTools 的设备模拟复现，确认是事件问题还是布局问题；事件问题查控件的触摸支持配置，布局问题用元素检查看点击区域的实际边界。移动端适配别等最后做，越早碰越省事。

5.3 本地跑得好好的，部署后资源 404

现象：本地file://或者本地服务器打开完全正常，传到托管服务器上样式全丢、图片裂开。

原因：路径写成了绝对路径或者相对路径层级算错，本地目录结构和服务器目录结构不一致；另一种是大小写问题，本地文件系统不区分，服务器区分。

解决：统一用相对路径，部署前在本地起一个跟服务器目录结构一致的静态服务器跑一遍；文件名全部改成小写加中划线，这条规则土但有效。

5.4 第三方 JS 库引入顺序成玄学

现象：单独引某个库没问题，和另一个库一起引就报undefined，调整顺序有时候好有时候不好。

原因：库之间有隐式依赖，加载顺序决定了全局变量什么时候可用；异步加载和同步加载混用也会导致时序错乱。

解决：把所有第三方库的加载方式统一（要么全同步，要么全用显式的依赖声明），并在引入后加一段自检代码，确认关键全局对象存在再往下走。别靠“调顺序试试”，那是碰运气。

5.5 老 Delphi 代码搬过来能编译但跑不通

现象：单元搬进新项目，编译通过，运行时报方法找不到或者返回值不对。

原因：依赖了桌面环境才有的东西——文件系统、注册表、本地设备、Windows 消息循环。这些在浏览器里没有对应物，编译期不报，运行期才炸。

解决：搬之前先做依赖扫描，把所有碰本地环境的调用列出来，逐个决定是替换成 Web 等价物、挪到服务端、还是砍掉。这个清单越早列越好，别等跑到一半才发现。

6. 三类人各自的答案，和一个我强制自己走的检查习惯

把前面几章收成结论，按人分。

第一类，全新项目、团队没有历史 Delphi 包袱、后端只提供 REST 接口。这类项目我倾向 TMS WEB Core，理由是产物是静态文件，部署和回滚都是文件级别的操作，CI 接起来干净，跨平台分发也不用为每个平台单独打包。代价是团队要接受“调试要看浏览器”这个转变，源映射和产物检查得当成日常习惯。

第二类，老桌面业务要整体搬到浏览器、UI 复用优先、团队不想重学前端。这类项目 IntraWEB 或 uniGUI 更顺，老代码能带着走，业务逻辑改动小。但要提前算清服务器侧的账：常驻进程、并发连接、弱网体验，这三项在立项时就要写进容量规划，别等上线了才发现机器不够。

第三类，混合形态。我见过做得最稳的一个组是这么干的：新增模块用 TMS WEB Core 写，独立部署、独立发版；老系统原封不动，两边通过 REST 对接。好处是新东西可以按新节奏迭代，老东西不用动，风险被切开了。坏处是要维护两套构建流程，得有人盯着。

最后说一个我强制自己走的习惯。从那以后我每次立项前，都强制自己走一遍四件事：把项目里最复杂的页面在目标框架的控件列表里对一遍，对不上的记下来；把调试入口写进团队文档，明确“出问题先看哪里”；把部署目标写成一个具体的目录路径，而不是“到时候再说”；把老代码里依赖本地环境的调用圈出来，逐个决定去留。这四件事做完通常只要半天，但能省掉后面好几周的返工。

这套流程不是万能的，它只是把“凭感觉选”变成“有依据地选”。真到项目里，还是要靠一次次小实验去校准。希望帮到你。

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