可能会有一些边缘情况，你在内联函数中有一个向量访问在内联函数中，你已经超出了编译器将内联的范围，它将强制函数调用。这种情况太罕见了，不值得担心——总的来说，我同意litb的观点。

我很惊讶居然没有人提到这一点——不要担心性能，直到它被证明是一个问题，然后进行基准测试。

如果使用向量表示多维行为，则会对性能造成影响。

2d+向量会导致性能下降吗?

其要点是，每个子向量都有大小信息，因此会有少量开销，并且不一定会有数据序列化(与多维c数组不同)。这种串行化的缺乏可以提供比微优化更大的机会。如果你在做多维数组，最好扩展std::vector并滚动你自己的get/set/resize bits函数。

向量使用的内存比数组多一点，因为它们包含数组的大小。它们还会增加程序的硬盘大小，可能还会增加程序的内存占用。这些增加很小，但如果您使用的是嵌入式系统，则可能很重要。尽管这些差异很重要的大多数地方都是使用C而不是c++的地方。

假设一个固定长度的数组(例如int* v = new int[1000];vs std::vector<int> v(1000);， v的大小保持固定在1000)，唯一真正重要的性能考虑因素(或者至少对我来说，当我处于类似的困境时)是访问元素的速度。我查了一下STL的向量代码，下面是我的发现:

const_reference
operator[](size_type __n) const
{ return *(this->_M_impl._M_start + __n); }

这个函数肯定会被编译器内联。所以，只要你计划对v做的唯一一件事就是用operator[]访问它的元素，看起来在性能上不应该有任何差别。

两者之间的性能差异很大程度上取决于实现——如果你比较一个实现得很差的std::vector和一个优化的数组实现，数组会赢，但是反过来，vector会赢……

As long as you compare apples with apples (either both the array and the vector have a fixed number of elements, or both get resized dynamically) I would think that the performance difference is negligible as long as you follow got STL coding practise. Don't forget that using standard C++ containers also allows you to make use of the pre-rolled algorithms that are part of the standard C++ library and most of them are likely to be better performing than the average implementation of the same algorithm you build yourself.

也就是说，以我之见，vector在使用调试STL的调试场景中胜出，因为大多数具有适当调试模式的STL实现至少可以突出/清除人们在使用标准容器时所犯的典型错误。

哦，不要忘记数组和vector共享相同的内存布局，因此您可以使用vector将数据传递给需要基本数组的遗留C或c++代码。但是，请记住，在这种情况下，大多数赌注都是无效的，您将再次处理原始内存。

选择STL。没有性能损失。这些算法非常高效，它们在处理我们大多数人不会想到的细节方面做得很好。