要系统化和全面的描述、记录，很有难度和需要水平、知识。下面是自己实际开发中遇到一些问题小计，和合理化方法。
1.递归删除.svn文件夹
find $(pwd) -name .svn | xargs rm -rf
知识点：查找命令find、whereis、grep；取命令输出$(pwd)（顺便：$LD_LIBRARY_PATH取变量值）；管道连接符|（顺便：重定向符<、>、追加符>>；丢弃输出/dev/null）；非常见命令xargs
2.无法打开文件
由于权限问题，文件明明存在，结果程序就是找不到。在linux上，别以为是程序错误，记得先考虑下该问题（顺便：没有权限执行，可能是文件没有可执行属性——chmod +x）。
3.JPEG parameter struct mismatch
该问题在网上找了好久，结果没有找到解决我问题的答案。如果有人也遇到该问题，这里分享一下我的解决办法：在编译libjpeg的make文件里定位输出生成jpeg的地方（如我的第三方makefile是这么写的$(CMD)(sh ./configure $(EXT_BUILD_ENVS) $(EXT_BUILD_JPEG); make $(EXT_BUILD_ENVS) libjpeg.a; $(P_RANLIB) libjpeg.a)），打印出相关参数，前台运行同样的./configure，生成jconfig.h替换掉原来的jconfig.h，这样前后台的libjpeg库便一致了。
4.unix系so和windows系dll
so1内printf1 ——> lib1内printf ——> "lib1的printf"；
so2内printf2 ——> lib2内printf ——> "lib2的printf"；
app连接到so1、so2调用printf1、printf2，输出结果和windows不一样。如果dlopen，那么输出可能如预期（个人懒惰，未验证）。注意linux上该形式的复杂表现。
so1/so2可以不连接lib1/lib2生成成功（windows连接失败）。app连接so1/so2方式，app连接lib1/lib2即可成功（不连接亦失败）；dlopen方式，so需要连接到lib、否则dlopen失败。
5.习惯LD_LIBRARY_PATH
类似windows的PATH，一个是系统变量（需要export）,程序的正常运行通常需要他。