从抱怨到根治我为什么专门写一篇C2653的排查笔记如果你在VS2019里遇到过 error C2653: “xxx”: 不是类或命名空间名称大概率你当时的第一反应是愣一下然后怀疑自己是不是把类名拼错了。这个报错在C编译错误里属于高频选手但它有个迷惑性极强的地方——它只会告诉你找不到这个符号却不会告诉你为什么找不到。实际上头文件没包含、类名拼写不一致、命名空间写错、宏定义把标识符替换掉、条件编译把定义代码跳过了甚至依赖项目没来得及编译都会抛出同一句C2653。这篇文章不是给你抄一抄某个具体改法的而是把这句报错彻底拆开从编译器查符号的流程、最常见的几个触发场景、到我平时实际排查时使用的顺序和工具一次性理清楚。适合被C2653折磨过的初学者也适合想系统理解编译器工作方式的中级开发者。已经熟练到看报错就能定位的老手也可以跳着看看第五节那一节我整理了几个容易混淆的编译错误对比平时容易绕进去。1. C2653到底在说什么——先搞清楚编译器的查户口逻辑1.1 编译器不是靠猜来认名字的C编译器的前端在处理源代码时有一个非常死板的步骤它维护一张符号表遇到一个标识符identifier就到这张表里查这个名字是否已经登记过。登记过的名字会带上它的身份属性——它是一个类、一个命名空间、一个变量、一个函数还是一个类型别名。而C2653的意思就是编译器在当前位置、当前作用域里找不到名为这个标识符的类型或命名空间记录。这么说可能有点抽象。打个比方你在一所大学里要找张伟这个学生但全校没这个人或者这个人在另一个校区没转过来你只在当前校区找当然找不到。编译器也一样它的当前校区取决于你写了哪些头文件、当前在哪个命名空间里、用了什么using声明。C2653不是语法错误而是语义分析阶段的名字查找失败。这里有一个很重要的认知C2653不是一个具体的写法错误而是一类名字解析失败的错误。它的同类兄弟包括C2065未声明的标识符、C2039不是XX的成员、C2061语法错误: 标识符XX。C2819、C2238这些错误有时候也会和C2653一起出现因为它们有共同的根因——某个类型名没被看到或者没被正确识别。1.2 报错信息要怎么完整阅读VS2019的输出窗口里你看到的C2653报错一般长这样1------ 已启动生成: 项目: TestApp, 配置: Debug Win32 ------ 1main.cpp 1D:\work\TestApp\main.cpp(18,5): error C2653: MyClass: 不是类或命名空间名称 1D:\work\TestApp\main.cpp(19,1): error C2653: MyClass: 不是类或命名空间名称我见过不少新手只看后半句不是类或命名空间名称然后开始怀疑人生。实际上报错里最有信息量的部分是main.cpp(18,5)——它精确告诉你是哪个文件的第几行第几列。点这一行VS会自动跳到出错位置。然后你要看的是这个标识符前面的代码是什么。比如MyClass obj; // 如果MyClass没被识别报C2653 MyClass::doSomething(); // 如果MyClass没被识别报C2653但如果是一个MyClass obj;且 MyClass 没有被声明编译器实际报的可能是 MyClass: 不是类或命名空间名称而不是未声明的标识符。这里有点绕C2653偏向于这个名字在当前作用域里以某种身份出现过比如作为变量名或者完全没找到这个类型名跟C2065略有区别。在内层作用域里如果一个继承类的基类写错了名字报的就是C2653。如果一个变量的类型是某个类但那个类根本没声明一般报C2065。但林林总总的差异初学阶段不用太纠结反正排查思路是一样的。1.3 顺带说说IntelliSense和编译器的报错差异还有一种情况很折磨人编辑器里红色波浪线报了一堆错误但编译实际是过的或者反过来编译报C2653但IntelliSense却显示一切正常。这背后的原因在于VS的IntelliSense引擎和编译器前端并不完全同步。IntelliSense为了实时响应会对代码做一些宽容处理有些宏展开、头文件包含关系它没有完全模拟会出现误报或漏报。当你看到IntelliSense报错而编译通过时可以先考虑清理一下IntelliSense缓存而编译报错IntelliSense不报时多半是宏定义或条件编译在真正编译时才生效。具体到C2653我遇到过几次诡异的情况cpp文件里报C2653点开对应的头文件IntelliSense里类的定义是完好的类名也是对的。最后排查出来是头文件的#include被某个宏包住了在特定配置下没有被包含进去。所以不要100%相信编辑器CtrlShiftB跑一次真正的编译才是硬道理。2. 触发C2653的五大高频场景——对照你的报错自查这一节我按实际开发中出现的频率排序把最常见的五种场景展开说一遍。你可以对照自己的代码逐一排除。2.1 场景一头文件没有包含或包含顺序不对这是最高频的触发原因大概占一半以上。最常见的情况是你使用了某个类MyClass但包含MyClass定义的头文件没有通过#include引入到当前编译单元。举个例子// test.cpp int main() { MyClass obj; // 没有 #include MyClass.h必报C2653 obj.run(); return 0; }这里的解决方式很简单在文件顶部加#include MyClass.h但有时候问题不是没包含而是包含顺序不对。比如某个头文件A定义了自己的类但它内部用到类BB的定义头文件却是在A之后才被包含的。只要B的定义里没有用前置声明这时候就可能出问题。// 假设有个头文件 config.h #pragma once #include string // 没有#include Utils.h却使用了Utils::parse()这里的一个重要原则是每个头文件都应该自包含self-contained。也就是说头文件用到的任何类型都应当在这个头文件里通过#include直接或间接包含它的定义而不是依赖包含者恰好先包含了别的头文件。如果你的头文件依赖了某个定义又没有包含在某个编译单元里碰巧包含顺序对了能编译过去换一个地方就报C2653——这种时好时坏的问题最有迷惑性。自查方法双击报错位置看那个标识符是什么然后用CtrlShiftF在解决方案里搜它的定义。如果定义存在看当前cpp文件的include列表是否覆盖包含该定义的头文件。2.2 场景二命名空间不匹配或using缺失C里命名空间是名字解析的重要边界。如果你在全局作用域里写MyNamespace::MyClass obj;但上面并没有namespace MyNamespace的定义或者定义在别的命名空间中编译器就无法解析MyNamespace报C2653。更常见的情况是using namespace std; int main() { string s; // 合法因为使用了using namespace std; vectorint v; // 合法 return 0; }但如果不写using namespace std也没有std::前缀那string和vector都会报C2653。还有一种比较隐蔽的情况——命名空间嵌套导致的敏感度问题。比如你写了namespace App { namespace Utils { class Helper {}; } } // 在其他文件 App::Helper h; // 错误Helper在App::Utils里不在App里这时编译器会在App里找Helper找不到报C2653。正确的写法是App::Utils::Helper h;或者使用using namespace App::Utils;。实战经验建议项目里尽量少用using namespace xxx;到处铺尤其是大型命名空间如std。宁可多敲几个字写全限定名也不要为了省事引入作用域污染。这种方式能减少很大一批只有编译到后期才会暴露的C2653类问题。2.3 场景三类名拼写错误或大小写问题C是区分大小写的myclass、MyClass、MYClass是三个完全不同的标识符。因为笔误把其中一个字母打错而导致的C2653排查时往往非常浪费时间因为人眼会自动修正。我有一次排查一个C2653花了一个小时最后发现是getValue写成了getValuee编译器在查找getValuee这个类名时没找到。由于这个类名是别人写的我之前没见过所以看代码时压根没意识到拼错了。自查方法在报错行右键那个标识符选择转到定义如果VS提示找不到定义基本可以确定是拼写问题。如果你开启了IntelliSense输入的类名如果是正确拼写通常会有智能提示如果没有任何提示大概率是拼错了。另外还有个容易被忽略的情况windows.h等系统头文件里存在大量宏定义比如min、max、GetMessage等。如果你自己的类名和这些宏重名预处理阶段会被直接替换掉导致编译器看到一个完全不同的标识符然后报C2653。这种情况尤其容易出现在Windows编程中后面第五节我会专门展开讲。2.4 场景四宏把类名替换掉了C的宏在预处理阶段是纯文本替换发生在编译器真正解析代码之前。所以如果一个类名或者一个命名空间名恰好和某个宏同名编译时就会出问题。举个例子Windows编程中ERROR是一个宏值为0。如果你定义了一个枚举类enum class ErrorCode { ERROR 0, // 编译错ERROR已经被宏定义了 WARNING };在某些情况下编译会报错。但如果是类型名冲突就可能是C2653。比如#define Config 100 class Config { public: void load(); }; int main() { Config c; // 预处理后变成了 100 c; c.load(); // 报C2653因为100不是类 return 0; }Config被宏替换成100编译器看到的有效代码是100 c;它尝试解析c的类型但100不是类也不是命名空间于是报C2653。这种问题在集成第三方库时特别常见尤其是C库和C库混用的时候。排查技巧在报错行上右键 - 快速监视或者用预处理输出的方式来确认宏是否替换了标识符。更快的判断方法是查看报错信息里显示的名字是不是和你写的不一样。如果报错里出现一个你没见过的名字多半是宏替换。2.5 场景五条件编译把定义跳过了#ifdef、#ifndef、#if这类条件编译指令在代码里很常见。如果你的类定义在某个未激活的条件分支里编译器根本不会看到这个定义用它的地方自然就报C2653了。比如// MyClass.h #pragma once #ifdef ENABLE_NEW_FEATURE class MyClass { public: void run(); }; #endif而你使用的cpp文件里没有定义ENABLE_NEW_FEATURE这个宏那么#include MyClass.h int main() { MyClass obj; // C2653因为MyClass这个类在整个编译单元里不存在 return 0; }这种场景在大型项目里非常坑。代码是在别人的机器上写的别人编译过了你拉下来编译却报C2653。原因往往是预处理器宏配置不一致——别人开了ENABLE_NEW_FEATURE你没开或者不同项目配置Debug/Release预定义宏不同。排查技巧如果类定义头文件里出现了#ifdef、#if、#ifndef就需要检查项目配置里的预处理器定义项目属性 - C/C - 预处理器 - 预处理器定义确认你需要的宏是否被定义。也可以用VS的转到定义功能如果编译器找不到定义而代码里确实有这个类就很可能被条件编译屏蔽了。3. 从编译日志到产出修复——我平时使用的排查链路与其对着报错想为什么不如按一套固定的顺序排查时间和效率上更有保障。我自己的排查顺序基本是看报错位置前后文 - 检查包含关系和命名空间 - 全局搜索定义 - 预处理输出辅助 - 检查配置差异。下面拆开来详细说。3.1 第一步从报错行附近找出线索代码VS的报错定位到行和列之后不要急着改。先把报错行往上看10~20行尤其是找有没有typedef、using、namespace、class之类的声明。因为C2653报出来的名字往往是你在某个局部作用域里写的一个类型这附近一定有一段代码引用了它。比如typedef std::mapint, MyClass MyMapType; MyMapType m; // 这里如果MyClass不可见报的也是C2653有时候是C2065那么线索就在 typedef 那一行。与其盯着下面的使用处看不如先检查MyClass是否包含了定义。另外如果是类内部的成员声明报C2653那说明这个类定义所在的头文件在编译到该行时缺少了那个类型的定义。比如// A.h #pragma once #include B.h // B.h里的某个类定义 class A { B b; // 如果B的完整定义未被包含会报C2653 public: void test(); };这里有个细节如果成员变量是B* b;指针编译器只需要前置声明class B;就能过。但如果是B b;对象必须有完整的定义。我把这两者的区别在5.2节再详细展开。3.2 第二步全局搜索定义与重名检查定位到报错的名字后按CtrlShiftF打开在文件中查找搜索范围选整个解决方案搜索这个标识符。这一步要搞清楚两件事第一这个类/命名空间是否真的存在 第二是否在多个地方定义了同名但不同的类/命名空间多个重名定义的情况比想象中常见的多。比如两个不同模块里各自有一个my_namespace如果你的cpp文件不小心把两个头文件都包含了又恰好使用using namespace编译器就会陷入两难有时候直接报C2653因为它不知道你指的是哪一个。如果搜索结果显示类确实存在那就确认包含路径和命名空间。右键项目 - 属性 - VC 目录 - 包含目录检查第三方库的头文件路径是否在列表里。如果头文件在另一个项目里确认是否设置了项目引用。3.3 第三步用预处理输出验证宏和头文件展开如果上面两步都没找到问题就需要动用预处理输出这个工具了。它能让你看到编译器真正解析的代码长什么样宏、条件编译、头文件包含的最终结果一目了然。操作方法是右键项目 - 属性 - C/C - 预处理器 - 预处理到文件选择是。然后重新编译编译器会生成一个.i文件里面就是预处理后的完整代码。这个文件可能很大几万行很正常但你不需要全部看——只需要在那个巨大的文件里搜索你报错的类名和所在行就行。在.i文件里你能看到该类名是否真的存在它被什么宏替换了它是否被#ifdef屏蔽了头文件是否真的被包含进来了如果没包含.i里就搜不到。这个工具非常强大建议每个C开发者都掌握。实际排查C2653时它往往是压轴级别的杀器。3.4 第四步对比不同项目的配置差异如果你的工程是多人协作或者在别人机器上编译正常但自己这里报C2653那第三类宏定义、预编译头、字符集都需要检查。尤其是预编译头设置这里特别想多说一句。VS项目默认会启用预编译头.pch通常是pch.h或stdafx.h。如果你的cpp文件使用了这个预编译头但你的类定义头文件没有在预编译头里被包含而是散落在某些源文件的#include中那不同cpp文件的可见性就可能不一致。比如ClassA定义在ClassA.h里main.cpp里包含了#include ClassA.h所以编译正常而foo.cpp里没包含恰好在foo.cpp里有一个函数使用了ClassA就会报C2653。检查项目属性 - C/C - 预编译头看是否使用以及创建/使用哪个文件。大型项目里这个配置不统一会引发很多莫名其妙的C2653。4. 举三个经典案例看C2653在实战中怎么一步步定位的说半天理论都不如看实际案例来得直接。这里我整理三个印象深刻的排查过程每个都是真实工作里遇到过的。4.1 案例一第三方库头文件版本混用导致的命名空间错位有一次做图像处理的项目用了OpenCV和一个自定义的SDK。SDK的头文件里声明了namespace CVEngine {}但SDK的某个版本里这个命名空间被改成了namespace CVMgr {}。项目里配置的SDK路径指向了旧版本但代码是新版本风格于是到处报C2653:CVEngine: 不是类或命名空间名称。这个问题的迷惑点在于SDK的头文件确实被包含了你打开头文件也能看到类都正常但用CVEngine的地方就是找不到命名空间。排查到最后对比了头文件里实际的命名空间声明才意识到是SDK版本不对。经验总结C2653报错里出现的名字搜索定义时要注意搜出来的定义是否和你的调用代码对齐——不仅类名要一样命名空间层级也要完全一致。如果发现头文件里的命名空间和代码里写的不一样先检查头文件版本和路径。4.2 案例二继承体系中基类名字被拼错有一次写一套UI组件库类层次是这样的class BaseWidget { public: virtual void render() 0; }; class Button : public BaseWidget { // 拼错成BaseWiget public: void render() override; };编译时Button这行报C2653:BaseWiget: 不是类或命名空间名称。因为BaseWiget这个名字根本不存在编译器在作为基类的上下文中查找它时找不到就报C2653。这种问题的排查效率取决于你对你自己的代码有多熟。我当时第一次没看出来是VS的查看所有引用和拼写检查插件提醒才发现的。那之后我学到一个技巧如果C2653出现在类定义的基类列表里优先怀疑基类名拼写和头文件包含。基类拼写错误时VS的IntelliSense一般会画红色波浪线但某些缓存状态下可能不画。另外还有一个衍生情况基类是模板类模板参数传递错误也可能导致C2653。比如template typename T class Base {}; class Derived : public Baseintt { // 拼错成intt };intt不是已知类型编译器在解析基类列表时会先解析模板实参找不到intt直接报C2653。4.3 案例三宏与类名冲突导致的神奇现象这个案例最有戏剧性。当时项目里引入了一个第三方的C库其头文件里定义了#define interface struct这是C语言模拟面向对象时常用的写法。而项目的C代码里恰好用了MSVC的__interface关键字并且有一个类叫class IInterface { public: virtual void init() 0; };因为interface被宏定义成了struct而IInterface这个名字本身不含 interface 这个词所以没直接冲突。但另一个文件里有个类叫Config这个Config恰好在第三方库里是另一个宏的定义所有使用Config做类型名的地方全部报C2653。当时花了很长时间才想到去快速监视里看那个报错的标识符展开后是什么——原来已经变成了一个数字常量。从那之后我遇到莫名其妙的C2653都会先去怀疑宏。经验总结如果报错信息里的标识符一眼看过去没有明显拼写错误头文件也包含了命名空间也对那就要立刻想到预处理替换。跳到预处理输出文件里搜索往往一眼就能看到问题。5. 容易和C2653混淆的兄弟错误——怎么区分和联动处理在实际编译信息里C2653很少单独出现。很多时候它会和C2065、C2039、C2238、C2819一起冒出来。它们的共同点是类型/名称解析失败但触发点略有区别。搞清区别不仅能帮你更快定位还能解释为什么有时候报错信息里既有C2653又有C2039。5.1 C2653 vs C2065 vs C2039错误码典型信息含义常见触发位置C2653XXX: 不是类或命名空间名称名字查找时该名字不是已知的类/命名空间类型声明处、基类列表、作用域限定符后C2065XXX: 未声明的标识符名字完全没有声明变量、函数的使用处C2039XXX: 不是YYY的成员YYY存在但XXX不是它的内部成员类成员访问、枚举访问简单归纳如果你写A::BA不存在时通常报C2653A存在但B不是A的成员时报C2039你用了一个裸的标识符B既没有声明也没有定义时报C2065。但要注意实际编译器执行顺序不一样。有时候一个MyClass::func()调用如果MyClass不存在报的是C2653如果MyClass存在但func不是成员可能报C2039或C2065。这里的边界在不同编译器版本上有细微差异不必死记硬背。5.2 前置声明和完整定义——C2653的一道分水岭C里同一个类型有两种已知程度前置声明forward declaration和完整定义complete definition。前置声明只告诉编译器这个名字是一个类但不能用来创建对象、访问成员或继承。class MyClass; // 前置声明 class Wrapper { MyClass* ptr; // OK指针只需要前置声明 MyClass obj; // 错误对象需要完整定义报C2653或C2079等 };这里有一个常见的坑一旦某个类型只做了前置声明你在使用这个类型的成员时编译器会报不同的错误。比如ptr-doSomething()会报使用了未定义类型C2027但如果是MyClass obj;则可能报使用了未定义类型或C2653不同编译器表现不一样。如果你看到C2653可以顺手看看报错的上下文是否涉及指针/引用 vs 对象实例。如果是指针或引用前置声明确实可以解决问题如果是对象实例就必须包含完整定义的头文件。比如在类A的头文件里class B; // 前置声明B class A { public: B* b_ptr; // OK不需要B的完整定义 B b_obj; // 编译错误C2653或者C2079 };这种问题在类之间互相引用时特别容易踩。A.h需要B的定义B.h又需要A的定义谁也不愿意先include谁最后就出现完整定义缺失某些地方报C2653。合理方案是类间互相引用时类成员尽量用指针或引用并在头文件里使用前置声明把完整定义放到cpp文件里。这样既解决了循环包含问题也避免了C2653这一族的错误。5.3 C2238、C2819和C2653的联合出现C2238意外的标记位于;之前和C2819类型没有重载operator-经常和C2653结伴出现。一个典型场景是SomeRegistry::SomeClass* ptr; // SomeRegistry不存在 ptr-method();编译器先遇到SomeRegistry无法解析报C2653接着解析SomeClass* ptr;时因为前面的一段失效可能报C2238后面ptr-method()由于不清楚ptr的类型又报C2819。也就是说底层原因其实只有一个SomeRegistry找不到后续一大堆报错都是连锁反应。所以排查C2653时不要被同时出现的一大片编译错误吓到优先解决最先报出来的C2653后面很多错误会自动消失。这也算是我用VS编译C多年的一点心得。6. 特殊场景实战Qt、第三方SDK和多人协作项目的C2653最后一个部分聊几个特定场景下的C2653这些场景里的触发方式和我前面提到的不太一样需要单独讲一下。6.1 Qt项目moc生成代码晚于编译单元的困境用Qt写界面时凡是继承自QObject的类只要用了Q_OBJECT宏就需要moc工具先处理头文件生成额外的C代码再交给编译器编译。如果moc步骤没执行、执行失败或者先编译了代码再运行moc就会在Q_OBJECT或信号槽相关的地方报C2653。常见表现是某个自定义类继承自QWidget编译时报Q_OBJECT: 不是类或命名空间名称。这个错误意味着moc可能没有正确运行或者类的头文件没有被纳入moc的处理范围。排查和解决右键项目 - 属性 - Qt Meta-Object Compiler (moc)确认头文件被列在额外包含目录里确认Q_OBJECT宏拼写正确包括大小写清空解决方案删除Debug/Release中间文件后重新生成确认项目文件.vcxproj里QtMoc规则没有被错误关闭。如果你是Qt和VS混用这个坑的频率不算低。因为moc生成的代码是自动的一旦哪一步断掉抛出来的错误又不像Qt自己报的新手很容易绕远路。6.2 第三方SDK头文件在但宏开关没开第三方SDK常见的情况是头文件里用了一堆宏来决定哪些API导出、哪些类型可用。有些SDK默认关闭某些特性只给了宏开关。如果你没定义对应的宏类定义可能直接不编译。比如某个SDK的头文件里有#ifdef USE_ADVANCED_MODE class AdvancedProcessor { public: void run(); }; #endif你的代码里用了AdvancedProcessor但项目里没有定义USE_ADVANCED_MODE编译器看到的头文件里根本没有这个类于是报C2653。这种问题排查的突破口是打开头文件对照报错的名字看它是否被某些条件编译指令包裹。如果确实被包着去项目预处理器定义里加上对应的宏。这类问题的难点不在解决而在想到去看条件编译这一步。所以这里强烈建议遇到C2653先别急着改代码先打开报错名字对应的头文件看看它周围有没有#ifdef/#if这种指令。6.3 多人协作拉取代码后C2653先检查是不是本地环境缺文件最后一种场景很现实。Git拉取同事的代码后编译直接报C2653这时候你的第一反应不应该是改头文件而是检查自己本地有没有缺失的文件、依赖项目有没有被拉下来、NuGet包是否还原成功、vcpkg/Conan依赖是否有问题。我在团队协作里多次遇到类似情况同事加了一个新的静态库但把库文件或者dll放在了Git LFS里我这边没装Git LFS拉下来的是一个文本指针文件而不是真的lib。链接阶段报错比较明显但如果是头文件的一部分没拉到C2653就会提前出现。排查建议确认所有子模块是否初始化完成git submodule update --init --recursive确认NuGet恢复是否成功右键解决方案 - 还原NuGet包确认vcpkg安装的第三方库是否完整vcpkg list确认第三方库的include路径是否匹配项目属性 - VC 目录 - 包含目录。把这些环境因素都排除之后再去看代码层面的问题效率会高很多。6.4 预编译头PCH带来的一大类错乱专门再强调一下预编译头因为它在多人协作、大型项目里太容易造成C2653了。预编译头的作用是加速编译把常用头文件提前编译成pch。但如果某个头文件没有加入预编译头而源文件启用了预编译头就会出现在某些cpp里可见、在另一些cpp里不可见的错乱。典型的报错规律是同一个类在某个cpp里用没问题在另一个cpp里用却报C2653排查头文件、include都没问题最后发现是预编译头设置不一致。解决方案有两个思路把公共的头文件加入预编译头或者不依赖预编译头保证每个头文件自包含。我个人的偏好是尽量让头文件自包含因为这样可移植性最好也能避免大量C2653之类的位置相关错误。写在最后的经验之谈C2653这个错误本身不可怕可怕的是它背后涵盖的排查维度太多。头文件、命名空间、拼写、宏、条件编译、项目配置、预编译头任何一环出问题都可能抛它。所以我个人的习惯是遇到C2653不慌按看位置 - 查包含 - 搜定义 - 预处理输出 - 对比配置这条链路走一遍大多数问题能在十分钟内定位。最后分享一个使用VS的小习惯打开工具 - 选项 - 文本编辑器 - C/C - 高级把启用IntelliSense和错误报告相关选项的日志输出打开有时候IDE会在后台输出一些比编译窗口更详细的信息。尤其在C2653伴随IntelliSense异常时这个操作能帮你发现一些编译窗口里看不到的线索。以上都是我自己在项目里踩过的坑和积累的经验不一定覆盖所有情况但按照这些思路走下来大部分C2653都能顺利解决。如果你遇到了这里没提到的奇葩变体欢迎按照这个排查框架自己去拆解——很多时候解决问题的过程比答案本身更有价值。