织梦收藏功能突然报错？别慌，排查思路都在这了

别让收藏按钮成了摆设，这事儿其实很搞心态

做织梦站的朋友应该都碰到过这情况：用户兴冲冲地点了收藏，结果页面要么没反应，要么直接弹出一串报错代码。这感觉就像你请人吃饭，菜刚上桌筷子断了，尴尬又扎心。很多新手这时候直接懵圈，到处搜教程，结果越改越乱。说白了，这故障大多是那几个老坑在作祟，今天我就把压箱底的排查经验给大伙儿唠唠，不整那些虚头巴脑的理论。

JS冲突是重灾区，这锅得让模板背

你有没有发现，收藏功能失效，往往发生在你换了个“高大上”的模板之后？这真不是巧合。织梦这套老系统，底层跑的是比较老版本的 JavaScript 库，而你新换的模板，为了特效炫酷，大概率引入了新版 jQuery。这就好比两辆车在单行道上互不相让，直接撞上了。

收藏功能的核心文件 plus/stow.php 以及相关的 JS 脚本，它们默认调用的是全局的 `$` 符号。一旦新版 jQuery 接管了页面，或者开启了 noConflict 模式，老代码就找不到对象了，点击按钮自然就跟没头苍蝇一样乱撞。

解决办法也很简单粗暴。打开你的模板文件，看看底部是不是引入了两次 jQuery？或者把收藏功能的 JS 代码里的 `$` 统统换成 jQuery 试试。要是实在搞不定，直接把新模板的 JS 库版本降一降，兼容性问题立马就能解决大半。

文件权限没给够，门都进不去谈何操作

这事儿吧，很多用 Linux 服务器的站长最容易忽视。咱们平时在 Windows 本地测试得好好的，一传到服务器上就歇菜。这时候别急着改代码，先去看看目录权限。收藏功能涉及到 < strong>member 目录下的读写操作，如果服务器把权限锁死了，程序想往数据库里写一条收藏记录，结果被系统一脚踢出来，它也没法给你报个错说“大哥我没权限”，只能在那儿装死。

赶紧去后台或者 FTP 客户端里，把 member 目录，以及 plus/stow.php 这些核心文件的权限，改成 755 或者 777。这一步做好了，很多时候那种“点了没反应”的玄学故障，自己就好了。别不信，这招我救过不少站。

数据库表前缀没对上，这锅得自己背

还有一种情况，特别让人哭笑不得。有些哥们儿为了安全，安装织梦的时候把默认的 dede_ 表前缀改成了别的，比如 mycms_。这本来是好事，防注入嘛。但是！你在手动修改核心文件，或者安装某些插件的时候，如果代码里硬编码了 dede_member_stow 这种表名，那就完犊子了。

程序傻乎乎地去 dede_member_stow 表里找数据，可你的数据明明躺在 mycms_member_stow 里。这就好比你去快递柜取件，单号上写的是 A 柜，你死命去撬 B 柜，能打开才怪。这时候赶紧打开报错提示，看看到底是哪个表找不到，去代码里把表前缀统一一下，故障立马消除。

终极排查：改代码前先备份

要是上面这几招都试过了，还是不行，那可能就得动真格改代码了。这里有个经典的坑，分享给大家。有时候是因为 archives_do.php 文件里的逻辑判断太严格，或者是因为会员组权限设置的问题。

你可以试着去 member/archives_do.php 这个文件里，把报错的那段代码注释掉，或者打印一下变量看看。比如这段代码：

```php // 检查用户是否登录 if($cfg_ml->M_ID == 0) { ShowMsg("你还没有登录，请先登录！","-1"); exit(); } ```

有时候系统没正确读取到 $cfg_ml 的值，就会一直提示你没登录。这种深层次的逻辑错误，就得靠 PHP 基础了，断点调试一下，看看数据到底是在哪一步丢的。记住，改之前一定要备份文件，别把站搞挂了再来哭。

写在最后

织梦这老伙计虽然年纪大了点，毛病不少，但只要摸透了它的脾气，其实挺好哄的。收藏功能这故障，看着吓人，无非就是权限、冲突、或者路径写岔了。别一上来就重装系统，那样显得咱们多不专业。按我说的这几个路子排查，哪怕你是新手，也能把这个问题按在地上摩擦。搞定了记得回来谢我，这可是多少个熬夜修站换来的血泪经验啊。