企业官网建设流程全解析

简介：多米影视管理系统（DuomiCms）是一套基于PHP与MySQL架构的免费开源影视建站程序，主要面向影视站站长、网站开发者以及PHP学习者。系统内置主分类、扩展分类、剧情分类三种分类方式，并配有一组丰富的模板标签，能够灵活调整页面布局，让站点呈现更专业的效果。压缩包共有489个文件，以PHP脚本、HTML页面、JS与CSS前端资源为主，同时包含SQL安装脚本、后台配置文件，以及若干GIF、PNG图片素材和字体文件，整体体积仅1.7MB，非常轻量。目前已有五百零八人学习下载。包内除了完整源程序之外，还附带了安装说明和多项安全设置建议，覆盖默认文档配置、安装目录清理、后台管理路径修改、子目录安装路径调整等常见部署要点。目录结构清晰，便于根据自身需求进行二次开发。对于想快速搭建影视站点，或希望通过真实项目学习分类体系设计与模板标签机制的开发者而言，这一套源码兼具实用价值与参考意义。

1. 多米影视CMS v1.21：一个自托管影视站点的PHP源码包，为什么还有人用它

拿到一个DuomiCms多米影视管理系统php源程序 v1.21.rar，第一反应可能是“这年头还有人用老掉牙的影视CMS？”但恰恰是这类产品，在自建影视站点、内部资料库、个人收藏整理这些场景里，反而比动辄几十万功能的商业系统更顺手。它本质是一套部署在自有服务器上的PHP + MySQL应用，用浏览器后台管理视频分类、影片信息、播放地址、会员权限，前台展示一个可搜索、可播放的影视站点。对想摆脱第三方平台限制、自己掌控数据和展示样式的个人玩家或小团队来说，这套东西依然有落地价值。但v1.21这个版本号也意味着它不是现成模板，环境兼容、伪静态、目录权限、PHP版本这些坑一个都绕不开。这篇文章就按“它是什么 → 怎么部署 → 后台怎么配 → 伪静态怎么弄 → 有哪些翻车现场 → 怎么加固”的顺序，把完整落地路径讲透。

2. 部署前先搞懂运行逻辑：环境要求、目录结构和安装流程

2.1 运行环境与必需组件：别急着解压，先看这三样

老一代影视CMS大都跑在LAMP / LNMP组合上，v1.21 也不例外。我一般先确认三件事：

• PHP 版本：这类程序大多兼容 PHP 5.6 到 7.0，个别老版本在 PHP 7.2+ 会报错，比如mcrypt函数消失、each()被移除。PHP 7.4 直接把很多老写法判死刑。
• MySQL 版本：建议 5.5 到 5.7，MySQL 8.0 的默认认证插件是caching_sha2_password，老程序连接时会直接 2002 或 1045，必须在 MySQL 里改成mysql_native_password。
• URL 重写：影视站点几乎所有内页都是伪静态地址，没有开启 rewrite，到处 404。

这几样里最容易踩的是 PHP 版本。我见过有人用 PHP 8.1 去跑，结果后台一片空白。你可以在宝塔、云服务器、虚拟主机上先建站，然后在探针或命令行里确认版本：

php -v php -m | grep -E "pdo|mysqli|curl|openssl"

上面第一行看版本，第二行查扩展。影视CMS 一般离不开pdo_mysql或mysqli、curl、openssl。缺了任何一个，采集和播放环节都会莫名失效。如果你用的是 phpStudy 或宝塔，建议先切换 PHP 版本到 7.0 或 5.6，再继续下面的步骤。

提示：不要用 Windows 自带的 php.exe 直接跑生产站，老程序在 Windows 上的文件路径和权限处理常有怪问题，能用 Linux 就跑 Linux。

2.2 解压与目录权限：把 rar 包变成能访问的站点

下载下来的v1.21.rar不是直接扔进网站根目录就能用的。压缩包一般包含程序文件、模板目录、上传目录、安装目录。我习惯先在本地解压，查看里面有没有install或install.php一类入口，再整体上传。

常见的解压命令（服务器上操作）：

# 先安装 unrar yum install unrar -y # 或 apt install unrar mkdir -p /www/wwwroot/movie mv ~/DuomiCms_v1.21.rar /www/wwwroot/movie/ cd /www/wwwroot/movie unrar x DuomiCms_v1.21.rar

unrar x会保留压缩包里的目录结构，e则把所有文件平铺到当前目录，这里必须用x。解压后你会看到类似application、template、upload、install这样的顶层目录。如果你的服务器上没有 unrar，也可以本地解压后用 FTP 上传，但上传必须保持目录层级，尤其要确认install目录没被漏掉。

接下来是最容易出问题的目录权限。PHP 写入缓存、配置、附件都靠权限，常见做法：

chown -R www:www /www/wwwroot/movie find /www/wwwroot/movie -type d -exec chmod 755 {} \; find /www/wwwroot/movie -type f -exec chmod 644 {} \; chmod -R 777 需要写的目录

到底哪些目录要 777？不能一刀切全设 777，否则被上传木马会很难受。我一般先给runtime、cache、upload、config这几个目录单独加权限：

chmod -R 777 /www/wwwroot/movie/runtime /www/wwwroot/movie/temp /www/wwwroot/movie/upload /www/wwwroot/movie/config

这只是起步，具体目录名因压缩包内部结构而异。如果安装时报“目录不可写”，再根据提示把对应目录放开。权限设置比你想的更绕，因为 Apache 和 Nginx 运行用户不同，虚拟主机还会夹一层空间权限。最稳妥的办法是先看进程用户：

ps aux | grep -E "nginx|apache"

确认是www还是nobody，然后chown给对应用户。这一步做不对，后面安装向导永远卡在“请设置目录权限”。

2.3 安装向导与数据库配置：五分钟跑通的步骤

在浏览器里访问http://你的域名/，如果程序带了安装跳转，一般会进到/install/index.php。整个过程大概三步：许可协议 → 环境检测 → 填数据库。环境检测页会直接告诉你哪个目录不可写、哪个函数未启用。很多小白在这一步看到一堆红色感叹号直接慌，其实大部分是 PHP 扩展没开。你需要检查 SQLite 支持？不，这里只关心pdo_mysql、curl。在 php.ini 里去掉对应扩展前面的分号并重启服务，红色消失后再继续。

填数据库时，有几项必须谨慎：

• 数据库地址：本地一般填localhost，如果填127.0.0.1，可能因为 socket 认证不同而连不上。
• 库名和用户：建议专门创建一个数据库，别共用 root 的超级生产账号。
• 前缀：默认可能是duomi_或db_，我习惯改成qm_这样无意义的组合，降低被猜表名拖库的风险。

安装完成后，程序会往数据库里写一份基础配置，然后一般要删掉或改名 install 目录。这一步千万别跳过。保留 install 目录等于把安装后门敞开，别人再次访问安装向导可以重置后台密码甚至清空数据。我一般会这样处理：

# 把 install 目录改成一个只有自己知道的随机名 mv /www/wwwroot/movie/install /www/wwwroot/movie/inst_bak_2025

如果有人事后想重装，再改回来就行。到这里，站点已经能打开前台页面了，但后台管理、分类数据、视频内容还是空的，下面进入真正耗时间的配置阶段。

3. 后台配置里必须拿下的六个模块：分类、视频、采集、播放器、模板和用户

3.1 分类与视频管理：避免数据混乱的层级设计

登录后台后，第一件事不是去开采集，而是先建分类。影视系统里分类是最容易被忽视的地基。常见的混乱是“电影”大分类下面直接挂数百个子分类，片源标签却乱成一团。v1.21 这类老系统的分类通常是两级：频道 + 子分类。频道可以是“电影”“连续剧”“综艺”，子分类可以是“动作”“爱情”“悬疑”。

我一般建议先在频道管理里把一级频道建好，再进入分类管理添加子分类，并绑定频道。这里有个容易忽略的点：如果分类的拼音别名会生成 URL 路径，那么分类改名后老链接会失效。所以在建分类前，先想好最终要展示的名称和 URL 别名，写下来再录入。

视频管理部分，添加一部影片通常要填：标题、分类、地区、年代、导演、主演、简介、图片地址、播放地址。v1.21 的播放地址一般放在“播放组”里，每个播放组有一个播放器和一个地址列表。我踩过最大的坑是：把“播放组”和“播放地址”搞混，导致前台页面打开了但点播放没反应。这里要认清：播放组决定用哪个播放器器，播放地址才是真正的视频源。

// 示例：视频提交时的字段映射（伪代码，仅说明逻辑） $video = [ 'title' => '某电影', 'type_id' => 3, // 分类ID 'playurl' => [ // 播放组数组 'player' => 'html5', // 播放器标识 'url' => 'https://example.com/video.mp4', 'episodes'=> '第1集', // 非连续剧可留空 ], ];

提交后，前台详情页会根据type_id取出分类，并根据playurl.player调对应播放器。所以如果播放器标识写错，前台会白屏。老系统中常见的播放器标识是youku、html5、vod、jq等，具体以你后台播放器列表里显示的为准，别自己编。

分类建好、数据录完之后，站点已经能手动跑通，但一个人这么录显然不现实，接下来就得靠采集。

3.2 采集配置：数据源怎么填、定时任务和过滤规则

影视 CMS 的采集功能是它的灵魂，也是最容易用出问题的地方。v1.21 的采集模块一般支持两类：接第三方标准接口（如 JSON / XML 资源站）和自定义采集规则抓取网页列表。作为自建站，我更建议用标准接口，因为网页抓取规则受目标站点改版影响非常大，几天就要维护一次。

进入采集管理→添加采集站点，一般要填：

• 采集名称：比如“自定义资源站A”
• 接口地址：一般是一个 URL，访问后返回 JSON 或 XML
• 资源类型：电影/连续剧/综艺
• 分类映射：把资源站分类对应到你后台的分类 ID
• 采集周期：手动采集或定时采集

分类映射是最容易出错的，它要求填当前系统里的分类 ID。如果资源站返回的分类是“动作”，而你的系统里动作片 ID 是 5，就必须在映射关系里写明“动作 → 5”。漏了这个，采进来的片子全部掉进默认分类，前台乱成一锅粥。

定时采集可以直接用系统自带计划任务，也可以挂在 crontab 上。我更推荐在服务器 crontab 里调用采集脚本或 URL 触发，避免老系统内置任务函数被 PHP 超时卡死。例如：

# 每天凌晨4点采集一次 0 4 * * * curl -s "https://你域名/index.php?s=collect&cid=all&key=你的密钥" >> /tmp/duomi_collect.log 2>&1

key参数一般是后台采集配置里自动生成的令牌，没有这个口子就自己加一个白名单判断。采集执行后，日志文件里会记录“成功XX条，失败XX条”。你不要只看成功数量，要看失败原因。常见失败：

• 超时：接口慢，PHP执行时间不够 → 在 php.ini 里调高max_execution_time，或改用命令行跑。
• 解析失败：接口返回变了字段名 → 查看接口返回的 JSON 结构，把映射字段改成实际返回的键名。
• 重复入库：同一部片子在多个资源站都有 → 根据唯一标识字段（通常是对应资源站的视频ID）做去重。

采集不是一劳永逸，我见过有人把所有分类自动采集了一轮后，发现简介和图片一堆空。原因很简单：没有设置“仅采集有简介”的过滤条件。所以添加采集规则时，尽量勾上“必须包含简介”和“必须包含图片地址”，少采点也比一堆死数据强。

3.3 播放器与模板：解析接口、显示样式和缓存

播放器是影视站的核心体验。v1.21 里播放器有两种：本地播放器（针对直链 mp4/m3u8）和外部解析播放器（针对网页版资源）。外部解析通常需要填写一个解析接口地址，但要注意：大部分现成解析接口并不可靠，经常挂或者会被防盗链拦截。常见做法是直接使用 HTML5 播放器，把视频直链填到播放地址里，这样最稳定。

在后台播放器管理里，通常会有一个“解析地址”的输入框。这个地址本质上是一个第三方网页服务：它接收视频原地址，然后返回一个播放页面。如果填的解析接口不稳定，就会导致前台“点播放白屏”。我自己更倾向使用支持html5的播放器配置，因为 m3u8 切片在手机端和 PC 端都有原生或 JS 支持。

模板方面，v1.21 多带几套默认模板，但老模板的列表页和详情页不一定友好。换模板时注意三点：

1. 模板目录名称必须和后台设定的模板名一致。
2. 模板里的{$var}标签不一定兼容所有版本的模板引擎，换版本前先保存一份原模板。
3. 模板中的图片懒加载和老版 jQuery 有冲突，导致列表页图片全部不显示。

我见过有人把一个全新模板传上去，后台设置切换后，前台乱成毛线。此时别急着删，查一下运行日志，看是模板引擎报错还是变量不存在。如果不知道在哪看日志，至少把 PHP 错误显示打开：

# php.ini 或运行目录 display_errors = On error_reporting = E_ALL & ~E_DEPRECATED

打开后刷新页面，如果出现“Undefined variable: xxx”，说明模板变量名对不上系统的数据数组名。解决方式是在对应模板里改变量名，不是去改程序核心，因为改核心以后升级会覆盖。

3.4 用户与权限：注册、VIP、积分的基础策略

影视站的用户体系大体分为游客、普通会员、VIP会员。v1.21 后台一般有用户管理和会员组设置，你可以配置注册是否开启、注册后是否需要邮箱验证、VIP权限按啥区分。

这里有个常见的思路偏差：不要只按“能否看多少个视频”来设置 VIP，老系统的播放权限一般靠“播放器允许播放的组”实现。每一个播放组（即播放器配置）可以设置哪些用户组可以看，游客不可看，普通会员看标清组，VIP会员看高清组。如果你希望会员制，就在添加播放组时指定可用用户组，而不是在前台视频详情页里写死“仅VIP”。

积分机制也是一样。v1.21 老版本可能支持签到或者积分兑换 VIP，但积分逻辑经常存在自定义扩展里。如果你只需要最简单的“每日签到 + 积分换时长”，可以用后台现有的积分系统，但注意兑换比率和发放记录。我自己的习惯是：先让用户登录，再签到三天，观察积分日志是否正常，再决定要不要对外开放。

注意：不要为了引流在用户中心置入任何与站外播放源相关的黄色或盗版内容，合规是一条红线，技术文章里更应该克制。

用户体系如果开得太大，还需要保护隐私和密码安全。老系统密码加密多数是 MD5，这已经是能破解的强度。若 v1.21 支持更换加密方式就换成更安全的 hash；不支持的话，至少做到后台密码不与他人共用，并定期备份数据库。

4. 伪静态与URL路由：让页面不404的Nginx/Apache配置

4.1 Apache .htaccess 与 Nginx rewrite 的等价写法

影视 CMS 的 URL 结构大体是index.php?s=detail&id=123这样的入口文件模式，如果开启伪静态，则会变成xxx/detail-123.html。这个变换依赖 Web 服务器的 rewrite 规则。

Apache 环境直接在站点根目录放.htaccess：

RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?s=$1 [L,QSA]

上面这组规则的含义是：如果请求的文件或目录不存在，把整个路径作为s参数交给index.php。L表示终止后续重写，QSA表示保留原有查询串。放在RewriteBase /后，list-动作片.html就会变相解析成index.php?s=list-动作片.html，再交给程序里自己的路由拆解规则。

Nginx 下没有.htaccess，需要写在 nginx 配置文件的server{}块里：

location / { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?s=$1 last; } }

if (!-e $request_filename)是“文件或目录不存在”的判断，rewrite后带了last表示重新进入 location 匹配。写成后执行：

nginx -t nginx -s reload

nginx -t是检查配置语法，看到syntax is ok再重载。如果直接 reload 有语法错误的配置，Nginx 会拒绝重启，但旧的 worker 可能已经停了，导致站点全挂。这门血泪经验我建议每个运维都记住：改完配置先测试再 reload。

4.2 常见404场景：伪静态失效、规则放错位置、缓存残留

伪静态配完，前台经常还是一片 404，这种情况我排过太多次，按出现频率排前三的原因是：

1. 规则放错了地方。Nginx 的 rewrite 被放进了location ~ \.php$块，导致所有非 php 请求直接 404，或者 Apache 的.htaccess放在了二级目录而不是根目录。检查位置：Nginx 规则必须在能匹配到该网站的server里；Apache 规则必须在站点根目录，而不是模板目录或上级目录。

2. 程序的路由配置里没开启伪静态。后台一般有个“URL模式”设置，选“伪静态模式”才会接收s参数。如果你后台仍是“动态模式”，rewrite 过去后就找不到对应路由，同样 404。这个最容易忽略，因为 Web 配置和程序设置是两层，两层必须一致。

3. 缓存里的旧链接。浏览器或 CDN 缓存了动态地址或旧的伪静态页。强制刷新无效后，可以加上随机参数?v=123打开。如果是在后台生成的 HTML 缓存，需要去缓存管理里清掉，否则页面永远显示缓存的旧内容。

另外有个容易被误判的：rewrite 后页面能打开，但所有 CSS/JS 找不到。原因多半是模板里的资源路径写的是绝对路径/tpl/xxx/static/style.css，而站点部署在子目录https://域名/movie/下，导致资源请求到了域名根上。这跟伪静态无关，是部署路径问题。解决方式是要么把站点部署在域名根目录，要么在配置项里统一加上子目录前缀。

5. 避坑指南：DuomiCms安装与日常使用中的6个典型翻车现场

5.1 现象：安装时提示“数据库连接失败”

原因大概率不是密码错误，而是 PHP 版本与 MySQL 的认证方式不兼容。MySQL 5.7 通常没问题，MySQL 8.0 默认认证插件是caching_sha2_password，PHP 5.6 的老 mysqli 驱动不认识。

解决：登录 MySQL 执行：

ALTER USER 'duomi'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码'; FLUSH PRIVILEGES;

把默认认证改回mysql_native_password。如果是虚拟主机没有 root 权限，联系空间商切换 MySQL 版本或临时开一个 5.7 库。

5.2 现象：安装完成后访问后台登录页，输入正确账号却登录后跳回登录页。

原因多半是 session 写入权限不够，或域名和配置里的 cookie 域名不一致。老程序在登录成功后会写入 session，如果runtime/session目录不可写，session 落不了地。

解决：先检查 session 目录权限，给它777并确认所用目录存在。再检查后台系统设置里的“站点域名”是否带http://，如果配置域名是旧的或写成了localhost:8080，同样会导致 cookie 回跳。把域名改成当前访问的域名，清掉浏览器 cookie，再登录。

5.3 现象：采集任务执行到一半页面白屏或 timeout。

原因是 PHP 脚本执行时间耗尽，通常是接口数据量大而且没开ignore_user_abort。

解决：临时调大max_execution_time。生产环境更建议用 shell 方式采集：

php /www/wwwroot/movie/cli_collect.php --cid=all

如果 v1.21 没有现成的 CLI 入口，就写一个简单的入口文件，在文件开头加：

<?php set_time_limit(0); ignore_user_abort(true); // 引入采集控制器 require './index.php';

这样脚本可以在命令行长时间跑，不受浏览器超时影响。别忘记在入口文件加 IP 白名单，防止被别人直接用浏览器触发。

5.4 现象：前台影片封面图全部显示成裂图，后台也看不到图片。

原因多出在图片防盗链或上传权限。如果图片是远程采集的，且目标站点设置了Referer防盗链，前台直接跨域拉图自然 401。

解决：先把图片下载到本地再存本地路径，或者开启 v1.21 自带的“下载图片”功能。本地化会让图片入库慢一点，但稳定得多。如果不想本地化，可以用一个简单的代理脚本去请求图片，例如：

// img_proxy.php 示例，仅示意 $url = $_GET['url']; // 校验协议和域名，防止SSRF header('Content-Type: image/jpeg'); echo file_get_contents($url);

但file_get_contents对防盗链和超时处理很弱，并且有 SSRF 风险，生产环境不要直接用。推荐用curl并携带目标站点要求的Referer，再缓存到本地。

5.5 现象：前台列表页只能显示一页，点下一页跳回第一页。

原因通常是伪静态 rewrite 的规则把分页参数丢了。比如原来动态地址是index.php?s=list-动作片&page=2，伪静态后误写成list-动作片.html，导致分页参数无法传递。

解决：查看分页链接生成规则，确认伪静态格式中包含了{page}。例如应该生成list-动作片-2.html。找到模板里的分页代码，看是否调用了pageurl类似方法，并确认后台的分页格式设置是list-{type}-{page}.html。改完后台设置后，清缓存再看。

5.6 现象：后台设置全部正常，但前台页面一片空白。

原因大概率是模板标签错误或 PHP 错误被屏蔽。老系统在 PHP 7 下，模板里用了each()、list()这类旧语法，会触发 fatal error 导致白屏。

解决：打开display_errors，看具体报错。如果看到Unsupported operand types或Function each() is deprecated，就定位模板文件，把旧语法替换成新写法。例如while(list($k, $v) = each($arr))改成foreach($arr as $k => $v)。如果自己没有能力改模板，就把 PHP 降到 5.6，让旧代码安静运行。但 PHP 5.6 已停止官方安全维护，所以只建议在内网或离线环境跑。

6. 进阶：性能优化与安全加固，让v1.21更健壮

v1.21 这类老程序，跑起来容易，跑得稳需要下一番功夫。性能优化的第一步是给页面加缓存。老系统的缓存机制通常分为页面静态化和数据缓存两种。我习惯在后台开启“生成静态页”，并设置内容更新时间，这样列表页和详情页直接让 Nginx 访问静态 HTML，底层 PHP 压力骤降。没有静态生成的话，就用 Nginx 的fastcgi_cache，配合proxy_cache给动态页面做一层代理缓存，但要注意老系统可能自带 cookie 报错，需要按用户登录状态跳过缓存。

安全加固比性能更紧迫。先把这几个必做项列出来：

• 后台入口改名：v1.21 的后台目录名通常是admin，我一般直接改成随机字符串，再在配置里同步修改。没改的话，扫描器几秒钟就能找到后台地址。
• 禁用安装目录：前面说过，install 目录要么删要么改名，这是最基本的。
• 防止 SQL 注入：老程序很多使用字符串拼接 SQL，手动传参容易出事。如果你不会改代码，至少把运行数据库账号权限压低：只给SELECT、INSERT、UPDATE、DELETE，不要给DROP、CREATE、ALTER。这样即使被注入，也很难直接拖库或删库。
• 定期备份数据库：我一般每天凌晨备份一次：

0 3 * * * mysqldump -u backup_user -p'密码' duomi > /backup/duomi_$(date +\%F).sql find /backup -name "*.sql" -mtime +7 -delete

备份只保留七天，既防磁盘占满，又能找回多数误删场景。

最后别忘了日志。老系统没有自带日志告警，但可以使用 Nginx 访问日志分析后台登录 IP。我用一行命令每周扫一次：

grep -E "POST.*(admin|login)" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

如果看到某个 IP 每天访问后台几十次，就要考虑加白名单或者更换后台地址。把这些做完，v1.21 虽然老，但在自己手里也算是一套能用的自托管方案。我自己的习惯是：每两个月重新检查一次目录权限，每半年换一次后台管理密码和数据库密码，平时不在游客可访问的目录里留任何调试文件。这套流程看着琐碎，但被扫描器“问候”几次之后，你会明白老系统最值钱的不是功能，而是你为它补上的安全习惯。希望帮到你。

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