性骚扰无处不在，简历上忘了去除联系方式，问我能不能穿丝袜？工资够不够住房？空窗期多久？？？

前两天在论坛看到一个女生发帖，说她投了份简历，结果碰上个“招鸡”的。

她说自己忘了把简历上的联系方式删掉，结果有人打电话来，说是要招聘，问她年纪多大、身高体重、能不能穿丝袜、有没有空窗期……

对方还一本正经地说“是文职工作”，但公司名字不说，职位内容不说，就一个劲地套你信息，那语气油得我都想给手机贴块吸油纸。

我觉得这种人简直是职业牛皮癣，专挑女生简历下嘴，猥琐得一塌糊涂。这要搁我们平时审代码，这种人直接打回重构，顺带再加个“终身拉黑”。

建议各位朋友简历里留信息时一定小心，别让这些网络流氓蹭上你的人生项目，白白消耗你的系统资源。

关于 Java 的 I/O 流，最早我也纳闷过：明明底层操作的都是字节，干嘛还要整出个“字符流”来画蛇添足？但等真正在项目里处理文件、调 socket、撸爬虫、写日志，走过一些坑之后我就明白了：字节流和字符流压根不是谁更高级，而是各有职责，谁用错谁出事。

Java 的 I/O 流确实是以字节为最小单位的，所有数据最终落地都得转成 byte。那为啥还得搞字符流这玩意？答案其实就俩字：方便。

举个栗子，我们用 FileInputStream 读一个文本文件：

FileInputStream fis = new FileInputStream("demo.txt");
int b;
while ((b = fis.read()) != -1) {
    System.out.print((char) b);
}

你以为你读出来的是“人类可读文本”？不，你读的是“字节转字符的运气游戏”。你猜的编码方式和文件实际编码对不上，直接变乱码，ñ#Ô€ 这种莫名其妙的字符分分钟给你整崩。

为啥？因为你硬用 (char) b 转换字节，根本不知道文件用的啥编码。比如 UTF-8 编码一个汉字通常是 3 个字节，你这边一个字节一个字节读，转出来能对吗？不乱才怪。

这时候我们看看字符流的做法：

BufferedReader reader = new BufferedReader(
new InputStreamReader(new FileInputStream("demo.txt"), "UTF-8"));
String line;
while ((line = reader.readLine()) != null) {
    System.out.println(line);
}

这里用了 InputStreamReader 明确指定编码，还加了个 BufferedReader 提升效率，一举两得。字符流就是在你搞定编码之后，把字节批量转成字符，操作上也更贴近我们处理“文本”的实际需求。

你可能问了：那为什么还要用字节流？干脆全用字符流不就得了？

想得美。你试试用字符流去读 MP3、JPG 或 zip 文件，分分钟整出个“乱码艺术展”。字符流只适合“文本类”数据，字节流才是“通用解法”。比如：

FileInputStream in = new FileInputStream("a.zip");
FileOutputStream out = new FileOutputStream("b.zip");
byte[] buffer = newbyte[1024];
int len;
while ((len = in.read(buffer)) != -1) {
    out.write(buffer, 0, len);
}
in.close();
out.close();

在复制压缩包的时候你就能体会到，啥编码都别给我扯，按字节搬砖才是正经事。

所以我觉得 Java 分字节流和字符流，其实是站在“开发者友好”的角度做的抽象。字节流是地基，字符流是楼上装修。文件底层肯定是字节，但人类可读的文本操作，直接用字符流才不至于疯。

至于有人说“字符流慢，因为要转码”，这话也没错，但现在大家都上 UTF-8，大部分 JVM 对常用编码的优化都不错了，真没必要因为“性能强迫症”就到处都用字节流。你要是天天处理百万级日志，行，咱单独聊优化。但正常项目里，能看懂、好维护比那几微秒重要得多。

当然，最魔幻的情况还得属——用字符流读 JSON，再用字节流 POST 上去，还得在 header 里写个 Content-Type: application/json; charset=UTF-8，这时候你才知道，字节流和字符流不仅要分清楚，还得“配合演出”。

所以最后我自己做的习惯是：文本用字符流，二进制用字节流，实在不确定就用字节流加转换器。

这东西说到底不是高深技术，而是生活经验。就像你炒菜要油，不代表你得喝油；但你真要热锅的时候，还得先倒油。这么一想，是不是也挺有哲理的？