企业官网建设流程全解析

简介：DeWeb 是一款面向 Delphi 开发者的网页化转换工具，无需掌握 HTML、JavaScript、Java、PHP、ASP 或 C# 等前端与后端语言，即可将既有 Delphi 程序快速改造成可在浏览器中运行的网页应用，并兼容手机、平板等各类客户端。本资源为 deweb2020-05-23 beta2 new2 版本，适合希望低成本迁移桌面程序、快速验证 Web 化方案的 Delphi 中高级开发者。压缩包共 2669 个文件，约 24.59MB，涵盖 pas、dfm、dpr、dproj 等 Delphi 源码与工程文件，dcu、obj、exe 等编译产物，以及 js、css、html 等网页资源，另含 icsV858 控件、多版本目录与示例工程，便于按 Delphi 版本取用。资源内提供安装控件、复制 dcu、编译运行及新建页面注册窗体的完整示例流程，并附带 demos、mobile、form4 等演示入口，可帮助读者快速跑通环境、理解页面注册机制并扩展自有窗体。目前已有 1073 人学习下载，可作为 Delphi Web 化实践的参考包。

1. 一个带日期和 beta 的压缩包名，为什么值得当成工程问题来拆

deweb2020-05-23 beta2 new2.rar这种命名，一线做交付的人一眼就能读出信息量：日期戳2020-05-23说明它是一次按天归档的构建产物，beta2说明它处在第二轮公开测试阶段，new2说明在 beta2 之后又被人手动改过一版，而.rar说明打包者用的是 Windows 上最常见的压缩工具，而不是 CI 流水线里常见的.tar.gz或.zip。它大概率是一个 Web 前端或全栈项目的整包快照，里面塞着源码、静态资源、依赖锁文件和一份不知道完不完整的说明。真正要解决的问题不是「怎么解压」，而是「怎么在不知道作者意图的前提下，把这个包安全地跑起来、验证它、并且判断它值不值得继续投入」。这篇写给需要接手陌生压缩包、做二次开发或技术预研的工程师，从目录结构一路讲到本地复现和踩坑。

2. 先别急着解压：从包名和体积反推项目形态

拿到一个.rar，很多人的第一反应是双击解压然后找index.html。这个习惯在 2020 年前后的项目上经常翻车，因为那个时间点的前端工程已经普遍依赖 Node 工具链，直接打开 HTML 大概率是一片白屏或者控制台报一堆模块加载失败。更稳的做法是先做静态侦察，用文件体积、文件数量和扩展名分布判断它到底是「纯静态站点」还是「需要构建的工程」。

2.1 用命令行做一次不落地的侦察

在 Linux 或 macOS 上，unrar和7z都能在不完整解压的情况下列出内容。我一般先用7z l看清单，再用unrar l交叉确认，因为有些老版本 rar 的头部信息两个工具解析结果不一致。

# 列出压缩包内容，不写盘，只看清单和大小 7z l "deweb2020-05-23 beta2 new2.rar" # 如果 7z 报错，换 unrar 再看一次 unrar l "deweb2020-05-23 beta2 new2.rar" # 只看顶层目录，快速判断项目结构 7z l "deweb2020-05-23 beta2 new2.rar" | awk '{print $NF}' | grep -E '^[^/]+/$' | sort -u

这三条命令的意图不一样。第一条给出完整文件树和每个文件的压缩前大小，用来判断有没有node_modules这种体积异常目录；第二条是兜底，老 rar 格式在部分 7z 版本上会提示「不支持的压缩方法」；第三条只抽顶层目录，输出通常只有几行，能立刻看出是src/、dist/、public/这种工程结构，还是html/、css/、js/这种上古静态站结构。

参数上要注意7z l的l是小写 L，不是数字 1，写成7z 1会直接报错。awk '{print $NF}'取的是每行最后一列，因为 7z 清单里路径在最后；如果路径里带空格，这个取法会截断，所以它只适合做粗筛，精确判断还得看完整输出。

2.2 从扩展名分布判断技术栈年代

把清单里的扩展名统计一下，基本能锁定技术栈。下面这段用7z l的输出做管道统计，比肉眼翻几百行快得多。

# 统计扩展名分布，取前 15 个 7z l "deweb2020-05-23 beta2 new2.rar" \ | awk '/^[0-9]{4}-/ {print $NF}' \ | grep -oE '\.[A-Za-z0-9]+$' \ | sort | uniq -c | sort -rn | head -15

逻辑说明：awk '/^[0-9]{4}-/'只匹配以日期开头的行，这些是 7z 清单里的文件条目行，能过滤掉表头和分隔线；grep -oE '\.[A-Za-z0-9]+$'抽出每行末尾的扩展名；后面就是常规的计数排序。如果输出里.js和.vue占大头，说明是 Vue 工程；如果.jsx、.tsx多，是 React 或 TS 项目；如果.php和.tpl多，那可能是老式服务端渲染；如果.html数量远超.js，才考虑纯静态。

这里有个经验值：2020 年 5 月的项目，如果.js文件里出现大量import语句但包里没有package.json，那这个包大概率是构建后的产物，不是源码，二次开发会很痛苦。反过来，如果package.json在顶层且dependencies里锁了具体版本，那它更可能是可复现的源码包。

2.3 判断是源码包还是构建产物

这一步决定后面所有工作方向。判断依据有三条：有没有package.json、有没有src目录、.js文件里是 ES Module 语法还是压缩后的一行。三条里满足两条以上是源码包，否则按构建产物处理。

如果是构建产物，别急着改代码，先找入口 HTML 和资源引用路径，确认它能不能直接托管。如果是源码包，下一步才是搭环境。

3. 把包跑起来：环境对齐和依赖安装的实操路径

侦察完确认是源码工程后，真正的坑才开始。2020 年的前端工程对 Node 版本很敏感，用现在的 Node 20 去装当年的依赖，十有八九在node-sass或node-gyp上翻车。这一章讲怎么把环境对齐、依赖装稳、启动命令跑通。

3.1 先读 package.json 里的 engines 和 scripts

解压后第一件事不是npm install，而是打开package.json看两个字段：engines和scripts。engines会写明作者当时用的 Node 范围，scripts里的dev、serve、build决定你怎么启动。

# 解压到独立目录，避免污染当前工作区 mkdir -p deweb-20200523 && cd deweb-20200523 unrar x "../deweb2020-05-23 beta2 new2.rar" # 查看关键字段，没有 jq 就用 node 读 node -e "const p=require('./package.json'); console.log('engines:', p.engines); console.log('scripts:', p.scripts); console.log('deps:', Object.keys(p.dependencies||{}).length)"

逻辑说明：unrar x的x是保留目录结构解压，别用e，e会把所有文件平铺到当前目录，几百个文件混在一起基本没法收拾。node -e那段是给没装jq的环境用的，直接 require 一个 JSON 文件在 Node 里是合法的，输出 engines、scripts 和依赖数量三个关键信息。

如果engines写的是"node": ">=10 <14"，那你就得准备 Node 12 或 13。用 nvm 切换是最省事的，别硬扛。

3.2 用 nvm 对齐 Node 版本

# 安装并切换到项目要求的 Node 版本 nvm install 12.22.12 nvm use 12.22.12 # 确认版本 node -v && npm -v

12.22.12是 Node 12 的最后一个维护版本，兼容性最好。选它的理由是 2020 年 5 月的工程绝大多数在 Node 12 上验证过，而 Node 14 虽然也兼容大部分语法，但部分原生模块的预编译二进制在 14 上可能缺失，会触发本地编译，编译又依赖 Python 2 和构建工具链，链路一长就容易断。

提示：如果机器上同时有多个项目，nvm 的use只对当前 shell 生效，开新终端要重新切。可以在项目根目录放一个.nvmrc文件，内容写12.22.12，之后nvm use不带参数就会自动读它。

3.3 依赖安装：锁文件优先，镜像兜底

装依赖的顺序是：有package-lock.json或yarn.lock就用对应命令，没有再用npm install让它自己解析。锁文件能保证装出来的依赖树和作者当时一致，这是复现的关键。

# 有 lock 文件时优先用 ci，它严格按锁文件装，不会改写 npm ci # 没有 lock 文件才用 install npm install # 网络慢时切镜像，只对当前项目生效 npm config set registry https://registry.npmmirror.com --location project

npm ci和npm install的区别值得说清楚：ci会先删掉node_modules再按锁文件精确安装，速度快且结果确定；install会尝试更新依赖并改写锁文件，在复现场景下这是副作用。所以只要锁文件在，一律用ci。

如果卡在node-sass编译，常见解法是换sass（纯 JS 实现）或者指定node-sass的二进制镜像。前者要改代码里的引用，后者加一行环境变量就行：

# 指定 node-sass 二进制下载源，绕过编译 export SASS_BINARY_SITE=https://registry.npmmirror.com/-/binary/node-sass npm ci

这个环境变量必须在npm ci之前 export，写在命令后面当参数是无效的，因为 npm 的生命周期脚本读的是进程环境。

3.4 启动和验证：看端口、看控制台、看网络面板

依赖装完执行npm run dev或npm run serve，具体看 scripts 里定义的键名。启动后要做三件事验证：终端有没有报编译错误、浏览器控制台有没有资源 404、网络面板里接口请求是不是全挂。

# 启动开发服务器，输出重定向到日志便于排查 npm run dev 2>&1 | tee dev.log

用tee是为了既能在终端看实时输出，又留一份日志。启动失败时先看dev.log最后 30 行，编译错误通常在那里。如果终端显示编译成功但页面白屏，打开浏览器开发者工具的 Console，八成是某个 chunk 加载失败或者路由 base 路径不对。

接口全挂是另一个高频情况。2020 年的项目经常把后端地址写死在配置文件里，本地跑起来后所有/api请求都指向一个不存在的域名。这时候要找vue.config.js或webpack.config.js里的proxy配置，把目标地址改成你能访问的测试环境，或者用 mock 数据顶一下。

4. 避坑与排查：接手陌生压缩包最容易翻车的五件事

这一章全是血泪经验，每条都按「现象 → 原因 → 解决」写，遇到对应情况直接对号入座。

4.1 解压后中文文件名乱码

现象：解压出来的目录和文件名显示成ÖÐÎÄ这类乱码，页面里引用的图片全部 404。

原因：.rar在 Windows 上打包时用的是 GBK 编码存文件名，Linux 和 macOS 默认按 UTF-8 解析，编码不匹配就乱码。

解决：用unrar时加-p不行，得用7z的字符集参数，或者装convmv批量转。更稳的做法是在 Windows 上用支持指定编码的工具重新解压，或者让打包方改用.zip并勾选 UTF-8 文件名。临时方案是convmv -f gbk -t utf8 -r --notest ./，但只对文件名有效，文件内容里的中文乱码得单独处理。

4.2 npm install 报错 ERESOLVE 依赖冲突

现象：npm install中途报ERESOLVE unable to resolve dependency tree，装不下去。

原因：项目里两个依赖对同一个包要求了不兼容的版本范围，npm 7 以后默认严格校验，直接拒绝安装。

解决：先试npm install --legacy-peer-deps，它退回 npm 6 的宽松策略，忽略 peer 冲突。如果还不行，用--force但要知道这是最后手段，可能装出运行时才暴露问题的依赖树。根治办法是找到冲突的两个包，手动在package.json里用overrides字段锁定版本。

4.3 启动后页面空白，控制台报 chunk 加载失败

现象：开发服务器起来了，浏览器打开是白屏，Console 里一堆Loading chunk xxx failed。

原因：构建配置里的publicPath写的是绝对路径（比如/static/），但你是从子目录或者file://打开的，资源路径对不上。

解决：找vue.config.js里的publicPath或 webpack 的output.publicPath，改成'./'相对路径。改完要重启开发服务器，热更新不会重新计算 publicPath。

4.4 接口请求全部跨域被拦

现象：页面能渲染，但所有数据请求在 Network 面板里显示 CORS 错误，状态是 failed。

原因：本地开发服务器和后端不在同一个源，浏览器同源策略拦截。

解决：在开发服务器配置里加代理。以 Vue CLI 为例，在vue.config.js里配devServer.proxy，把/api转发到后端地址。注意代理只在开发环境生效，生产环境要靠后端配 CORS 头或者同源部署。

// vue.config.js 里的代理配置示例 module.exports = { devServer: { proxy: { '/api': { target: 'http://127.0.0.1:8080', // 换成你能访问的后端地址 changeOrigin: true, // 改请求头里的 Host，绕过部分校验 pathRewrite: { '^/api': '' } // 后端没有 /api 前缀时去掉它 } } } }

changeOrigin设为 true 是为了让后端看到的 Host 是目标地址而不是 localhost，很多后端框架会校验这个。pathRewrite按后端实际路由决定加不加，配错了会 404。

4.5 构建产物部署后刷新 404

现象：npm run build出来的文件传到服务器，首页能开，但刷新子路由或者直接访问子路径就 404。

原因：前端路由用的是 history 模式，服务器没配 fallback，找不到对应文件就返回 404。

解决：要么把路由改成 hash 模式（URL 带#），要么在服务器配 rewrite 规则把所有未匹配路径指回index.html。Nginx 的写法是try_files $uri $uri/ /index.html;，Apache 用.htaccess的RewriteRule。这是部署问题不是代码问题，但接手项目时经常被当成 bug 查半天。

5. 判断这个包值不值得继续投入：三个验证动作和一个决策习惯

跑起来只是第一步，真正要回答的是「这个 2020 年的 beta 包，现在还有没有继续做的价值」。我的习惯是做三个验证动作，然后按结果决定是深入、归档还是放弃。

5.1 验证动作一：依赖安全扫描

老项目的依赖里几乎必然有已知漏洞，先扫一遍心里有数。

# 生成依赖树并做安全审计，只输出高危及以上 npm audit --audit-level=high # 导出完整依赖清单，便于离线分析 npm ls --all --json > deps-tree.json

npm audit的输出会列出漏洞包、严重等级和修复建议。重点看high和critical，moderate及以下在内部项目里可以暂时接受。如果高危漏洞集中在构建工具链（比如webpack-dev-server）而不是运行时依赖，风险相对可控，因为构建工具不进入生产产物。npm ls --all --json导出的树可以用来查某个包是被谁引入的，定位传递依赖时很有用。

5.2 验证动作二：核心功能冒烟测试

不看代码先点页面，把主要功能走一遍，记录哪些能用哪些报错。这一步的目的是判断「这个 beta 版的完成度」。如果核心流程能走通，说明它是个可用的基线；如果一半功能是灰的或者点了没反应，那它更像个半成品，接手成本会很高。

冒烟测试要覆盖：登录/鉴权流程、主列表页的数据加载、表单提交、路由跳转。每项记录「正常 / 报错 / 无响应」三态。报错的看 Console 和 Network，无响应的看是不是事件没绑定。

5.3 验证动作三：代码可维护性快评

打开src目录，随机抽三个业务文件看代码风格。判断标准是：有没有统一的目录约定、组件拆分是否合理、有没有明显的复制粘贴痕迹、注释是中文还是英文。如果三个文件风格差异巨大，说明这个包是多人拼凑的，后续维护会很痛苦。

再看一眼有没有测试文件。2020 年的 beta 项目大概率没有单元测试，这不是致命问题，但意味着你改任何东西都得靠手动回归，投入前要把这部分成本算进去。

5.4 一个决策习惯：先定「用多久」再定「改多少」

我接手这类历史包时有个固定习惯：先问清楚这个包是要长期维护还是只做一次性参考。如果只是参考实现，那就别修依赖、别升级工具链，跑起来看逻辑就行，改一行都是浪费。如果要长期维护，那第一件事不是加功能，而是把依赖锁死、把构建跑通、把冒烟测试脚本化，先有回归能力再动业务代码。

这个习惯帮我省过很多时间。有一次接手一个类似命名的包，花了两天升级依赖，结果发现它只是个演示 demo，业务方要的是里面的一个算法实现，直接抽出来就行，那两天纯属白干。所以顺序永远是：先判断用途，再决定投入深度。

希望帮到你。

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