vector声明初始化应按标准选择：空容器用vector v;，预分配用vector v(10);，初始化值优先用vector v = {1,2,3};；push_back与emplace_back依类型选，基础类型无差别，自定义类优先emplace_back；访问用[]（快但不安全）、at()（带检查）或front()/back()（需非空）；clear()不释放内存，需shrink_to_fit()或swap技巧释放。
vector 声明和初始化怎么写才不报错
直接写 vector<int> v;</int> 没问题，这是最安全的默认构造。但很多人一上来就写 vector<int> v(10);</int> 或 vector<int> v{1,2,3};</int>，结果在老编译器（比如 C++11 之前）或某些嵌入式工具链里编译失败——因为花括号初始化和带参构造的重载规则在不同标准下有差异。
实操建议：
- 要空容器：无条件用
vector<int> v;</int> - 要预分配 10 个默认值（全 0）：用
vector<int> v(10);</int>，确保编译器支持 C++11+ - 要初始化具体值：优先用
vector<int> v = {1, 2, 3};</int>（C++11 起），别省略=，避免某些旧 clang 版本误判为函数声明 - 跨平台项目（比如同时跑 MSVC/GCC/Clang）：避开
vector<int> v{1,2};</int>这种无等号写法
push_back 和 emplace_back 到底该用哪个
push_back 是“先构造再拷贝/移动”，emplace_back 是“在 vector 内部原地构造”。对 int 这种 trivial 类型，两者生成的汇编几乎一样，没区别；但一旦换成自定义类（哪怕只是含 string 成员），emplace_back 就可能少一次临时对象构造。
常见错误现象：有人写 v.emplace_back(1, "hello"); 结果编译失败，其实是因为 int 没有双参数构造函数——emplace_back 会把参数直接转发给元素类型的构造函数，类型必须匹配。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 存
int、double等基础类型：随便用哪个，性能无差别 - 存自定义结构体且你明确知道它的构造函数签名：优先用
emplace_back，比如struct Point { int x,y; Point(int x,int y):x(x),y(y){} };→v.emplace_back(3,4); - 不确定构造方式，或传的是已存在变量：用
push_back更稳妥，比如int a = 5; v.push_back(a);
访问元素时 []、at()、front()/back() 的取舍
v[i] 不检查越界，快但危险；v.at(i) 会抛 std::out_of_range 异常；front()/back() 要求 vector 非空，否则未定义行为——这三个不是性能梯度，而是“是否愿意为安全性多一次判断”的选择。
容易踩的坑：调试时用 at() 报错定位问题，上线后悄悄换成 []，结果某次输入异常导致越界访问，程序静默崩掉（尤其 Release 模式下没异常捕获）。
实操建议：
- 循环遍历确定长度：用
[]，比如for (size_t i = 0; i - 用户输入索引或配置文件读出的下标：强制用
at()，并包 try/catch - 只取首尾且你刚 check 过
!v.empty()：用front()/back()，语义更清晰 - 别在 assert 里用
at()，比如assert(v.at(0) > 0);—— Release 下 assert 失效，at()也跟着失效，变成裸[]
clear() 之后内存真的释放了吗
不释放。clear() 只销毁所有元素、把 size() 归零，但底层分配的内存（capacity()）保持不变。这是为了后续快速复用，避免反复 malloc/free 开销。想真正归还内存，得配合 swap 技巧。
典型场景：一个 vector 临时加载了上万条日志，处理完立刻 clear，但后续长期不用——此时它仍占着几 MB 内存，可能引发 OOM（尤其在内存受限环境如嵌入式或长时间运行服务）。
实操建议：
- 确认后续不会再往这个 vector 塞大量数据：用
v.clear(); v.shrink_to_fit();（C++11 起），但注意shrink_to_fit是请求，不保证执行 - 追求 100% 确定释放：用
vector<int>().swap(v);</int>，利用临时对象析构释放内存 - 频繁增删的场景（比如网络包缓冲区）：干脆别复用 vector，每次用完 let it die，靠 RAII 自动回收
vector 的 capacity 和 size 分离设计是合理的，但“clear 不等于释放”这点，十个人里八个第一次被内存泄漏吓到时才意识到。
