C++中FileHandler类内vector调用push_back抛出std::out_of_range错误

所有异常都来自Java与C++的构造、作用域规则的认知差，和vector成员的可编辑权限没有任何关联，核心错误点如下：

• 作用域遮蔽是最核心的触发点。你在构造函数、甚至后续新增的addFullPath方法里写的“对vector成员的独立声明”，本质是在函数栈帧内创建了和类成员同名的局部变量，完全没有触达类实例内存中存储的真实fullPath、fileNames成员。等函数执行结束，这些局部变量会直接被栈回收，类里的真实成员自始至终没有被做过任何修改。
• 跨语言认知偏差放大了问题。C++中只要在类定义段公开声明了std::vector<std::string> fullPath这类值类型成员，编译器在构造类实例时会自动调用该类型的默认构造函数，生成一个合法、可正常读写的空vector，根本不需要在构造函数里重复声明、手动“实例化”。你手动写的重复声明不仅没有初始化成员的作用，反而把真实成员给同名局部变量遮蔽了。
• “push_back执行后依然越界”的表现，本质是push_back操作根本没有作用到后续读取的那个fullPath对象上：如果是在类的成员方法里写了局部变量的遮蔽逻辑，字符串只会被push到临时局部vector里，类实例里的真实fullPath始终是初始空状态，调用at(0)自然会抛出越界错误。如果测试时通过值拷贝的方式获取FileHandler实例，对副本做push_back后，去读取原容器里的空成员，也会出现完全相同的越界表现。
• 关于“vector成员不允许被编辑”的怀疑完全不成立：std::vector的公开成员完全支持外部调用push_back、at等方法，只要拿到的是合法有效的对象引用，就不会出现操作权限层面的问题。

• 彻底删除构造函数、成员方法里所有和类成员同名的局部变量声明，从根源上避免作用域遮蔽：
  • 正确的构造函数不需要对已经在类里声明的vector成员做任何手动初始化，编译器会自动完成默认构造。如果需要自定义初始容量等参数，通过成员初始化列表显式完成初始化即可，不要在函数体里写重复的类型声明。参考正确实现：

    class FileHandler {
    public:
        // 公开声明两个vector成员，编译器自动默认构造为合法空vector
        std::vector<std::string> fullPath;
        std::vector<std::string> fileNames;
    
        // 显式默认构造即可，不需要额外函数体逻辑
        FileHandler() = default;
    
        // 正确的addFullPath实现，直接操作this指向的类成员，不创建同名局部变量
        void addFullPath(std::string path) {
            this->fullPath.push_back(std::move(path));
        }
    };
    

• 测试时确保拿到FileHandler实例的有效引用，避免值拷贝导致的操作错位：
  • 从std::vector<FileHandler> fileHandlers中获取实例时，直接通过at(index)返回的引用操作即可，不需要额外拷贝成临时变量。操作完成后读取同个引用下的fullPath.at(0)，不会再出现越界。
• 可通过打印fullPath.size()做辅助校验：push_back执行后如果size为1，就说明操作已经正确作用到真实成员上，此时调用at(0)一定是合法的；如果size始终为0，就说明存在作用域遮蔽、引用失效的问题。

内容的提问来源于stack exchange，提问作者David