MarginNote，强大的整理思维和深度阅读工具，忠于知识内化的理念，好读书，却不“迷信”书。牛津大学图书馆（Bodleian饱蠹楼）的书不外借，而且读书只准携带笔记本和铅笔，这样的要求养成了钱钟书边读书边摘录的习惯。现在，全新的无纸化深度摘录利器MN，将这一过程数字化，倍化效率，分享经验，传播爱书者的精神，此刻，欢迎来到论坛的你，加入这一使命。
MarginNote在阅读文献方面可以说已经说已经做到了极致，但当论文非常多的时候，查找管理文献就不是很方便了。Mendeley，Endnote之类则恰恰相反，找论文很方便，但它们内置的pdf浏览器比较鸡肋。如果存在合作的可能性，是否可以使献管理软件引用条目的全文附件支持MarginNote格式，这样点开全文时能用MarginNote阅读和批注，之后又能十分有条理地分类保存在Mendeley，Endnote中，体验会非常好。
更好的情况是，MarginNote自身加入识别pdf文件后生成引文信息的功能，优化一下文件分类，甚至加入在word里插入引文信息的功能，这样的话就真的完美了。
你说的这些功能感觉不是很现实，客观原因是marginnote已经在功能非常复杂了，开发者团队很小精力有限，更新修复已有的bug都已经感觉有点儿力不从心了，不大可能添加这么大一块数据管理功能，文献识别是个大工程。
不过你目前的需求跟我一样，经过长期摸索，告诉你一个完美解决办法，看完你一定会很感谢我，哈哈哈哈哈
！你仅仅需要把mendeley的归档文件夹设置到iCloud的marginnote文件夹里就行了，一分钟搞定你的需求！以后阅读文献时，在mendeley里搜索到相应的文件，然后右键单击Open File Externally就可跳转marginnote做批注了。
好的谢谢！！我试试
我自己花了近一千多买了个正版EndNote，如果Marginnote做到这些，我再花一千也无妨(´･_･`)
感谢seantan521的建议，如果是Mac使用，还有一个更好的办法：
直接设置MN内置资源库文件夹为Mendeley的归档文件夹。MN的同步机制是复制icloud文件，故该资源库文件夹同时包括了icloud同步文档和本地文档。
/System/Volumes/Data/Users/用户 名/Library/Containers/QReader.MarginStudyMac/Data/Documents
参考
啊啊啊，看的感觉好复杂呀……我用的EndNote，本身还有EndNote自带的同步服务，会不会有冲突呀
同步方面，如果您按我给出的路径添加为资料库（不确定Endnote是否支持自定义资料库位置），MN内的同步不开启的状态下，就不冲突，但是MN的笔记和文档是独立存储的，这样笔记就需要您自行备份了、
endnote它只会同步文档，不会同步MN的笔记数据
我把Mendeley的归档文件夹设置在了dropbox里, 那可以把MarginNote的内置资源库文件夹也设置在那里吗？
可以借助Bindfs挂载一下，改变MN内置资源库的位置。
谢谢，用bindfs改掉了
你好，我想问问你，改完后就是Dropbox同步marginnote的文件吗？不再需要借助iCloud？
不是的，MN的笔记数据是特殊的数据库格式，这个不能被第三方软件同步的，第三方软件只能同步MN的文档文件。其关联笔记不受影响
我遇到的问题是 MarginNote 会打乱 Zotero 的文件存储的位置。
因为想利用 iCloud 的优势，我直接把 Zotero 的 library 设置到了 MarginNote 在 iCloud 的目录内，这样在 Mac 和 iOS 设备上都可以阅读文件。
Zotero 会把 pdf 文件存在其 storage 文件夹下的名字比较“随机”的子文件夹内。如果在 Zotero 内设置默认用 MarginNote 打开 pdf 文件后，通过 Zotero 打开 pdf 时，MarginNote 会自动把 pdf 从 Zotero 的文件夹内移动到 MarginNote 的根目录下。这时再想从 Zotero 内打开 pdf 就会失败，因为已经被 MarginNote 移走了。但如果通过 Finder 进入子文件夹，在 pdf 上选择“用 MarginNote 打开”，MarginNote 可以正常打开 pdf 并且不会移动 pdf 到根目录下。 之后在 Zotero 打开 pdf 也不会有问题。虽然通过这种办法能够实现目的，但是也相当的麻烦，不知道有没有更好的解决方法。
另外，把 Zotero 的 library 整体放在 MarginNote 文件夹内的一个副作用是，每次想在笔记本内加入新的 pdf 时，会有一大堆文件出现在列表上。
您好，请参考我的bindfs教程及其同步tips中关于MN同步机制的说明： @hyh3
MN不会直接读取Icloud中的文件，而是将其复制到MN资源库内。即MN实际上只能打开其资源库预制目录内的PDF，不论你采取什么方法，这都是一个基本的前提。你需要通过bindfs把相关文件投射到MN资源库内。
您好，感谢您的回复。我设置的mendeley的归档文件夹是：
/Users/用户名/Library/Mobile Documents/iCloud~QReader~MarginStudy/Documents/Mendeley Desktop
而您给的建议是：
/System/Volumes/Data/Users/用户名/Library/Containers/QReader.MarginStudyMac/Data/Documents
请问这两种方法有啥区别么？哪个才是正确的MN内置资源库文件夹？
zotero 的那个文件管理感觉真的有一点点乱，那个 zoteofile 还是什么插件你有试过吗？
zotero的本地文件管理完全看不懂啊…不如mendeley简单直接方便
尝试过。zoterofile 可以将 pdf 转存到指定的地方，并且自定文件夹结构和文件名。但是 zoterofile 操作起来有那么一些繁琐，似乎不能实现导入 pdf 自动转存，除非使用浏览器插件保存文章 pdf。再加上一些其他原因，我暂时先用 Mendeley 了。但是我感到真正麻烦的地方可能还是在于 MN。
过去我以为遇到的问题是 MN Mac 会自动把 pdf 从 Zotero 的目录下移动到 MN 的 iCloud 根目录下，这样就破坏了 Zotero 文件夹的结构，再从 Zotero 里打开就会找不到文件（我想大家希望的都是在文献管理软件中管理文献，在文献管理软件中选择用 MN 打开 pdf）。但是我后来发现这不是 Zotero 的问题。只要不是在 MN Mac 内打开，文件都会被移动到 MN 的 iCloud 根目录下。比如通过 Mac 右键菜单选择用 MarginNote 打开一个文件后，那个文件也会被自动移动到根目录下。
另一个现象是当我更改了位于 MN 的 iCloud 内 pdf 文件名称后，在 MN Mac 里看 pdf 还是原来的名称。如果在 MN 的 iCloud 内删除一个文件后，那个文件仍然可以在 MN Mac 里存在并可以被打开。后面我发现这个可能和 MN Mac 的存储机制有关。
当一个文件被拖入 MN 的 iCloud 内后，MN Mac 会把那个文件在“/System/Volumes/Data/Users/用户名/Library/Containers/QReader.MarginStudyMac/Data/Documents”复制一份（含文件夹结构），作为本地存储。以下是我的猜想。如果不是在 MN Mac 内打开文件，比如上面举例的通过 Mac 右键菜单选择用 MarginNote 打开，MN 首先会发现“没有在我的本地存储内找到这个文件”，然后就会移动文件到本地存储的根目录下。因为开启了 iCloud 同步，这个文件又被复制到了 MN 的 iCloud 的根目录下。表面上看来就是一个在 MN 的 iCloud 下的文件夹内的文件被移动到了根目录下。这也可以解释改名和删除的现象。即使 iCloud 内的文件被删除，那个文件仍然可以在 MN 的本地存储内被找到，只不过就是不算被同步了而已。
至于为什么 MN 要这么做，一方面可能是为了性能以及符合苹果规范，另一方面可能更是和设计哲学有关系吧。MN iOS 只能使用存储在 MN 的 iCloud 内的文件及笔记本。如果想打开 iCloud 上的非 MN 目录下的文件就只能通过导入复制一份的方式。我记得有很多其他 PDF 阅读类 App 其实是可以直接访问 iCloud 内任意位置的文件的（我个人偏好按照课程来建立文件夹，而不是把所有需要阅读的文件都统一放在一个目录下。能访问 iCloud 任意位置就会很方便了。）。MN 之所以不这么做的一个可能的原因是笔记本。MN 对 pdf 的注释和笔记本是独立于 pdf 本身分开储存的。如果设计了打开外部文件功能的话，只能建立一个笔记本和源文件的链接。如果外部文件的位置变化了就会变得有些麻烦。但是这样做的代价是如果想在 Mac 上访问外部文件只能用符号链接（猜想，没试过）或者 bindfs 来实现。进一步的代价是 MN 和其他 App、软件协作很难，因为上面提到的文件存储的问题，而且注释默认不是嵌到 pdf 文件内的，其他地方也看不到。
不过我暂时没有尝试 bindfs，我觉得这样无法通过 iCloud 和 iOS 上的 MN 协作（猜想，没试过）。而且如果麻烦超过了一个阈值就想先不管了。目前我使用的是把 Mendeley 目录放在 MN 的 iCloud 目录下，并始终通过 MN Mac 打开文件的方式。至少在文献还不多的情况下还可以应付下去。
对于几个猜想我备注下
1，MN Mac会自动确保icloud和内部资源库目录均有一份PDF文件，哪里没有复制哪里，故如需与文献管理软件协作，关闭相关项目的Icloud可以避免复制。
2，MN不支持符号链接，唯一支持的方案是Bindfs，Bindfs也没有那么麻烦本身是一个程序，需要配置的是开机自动挂载，把文献管理软件的数据库文件夹挂载到MN内部资源库目录，此时如未开icloud，MN会视为不需要任何复制，不会破坏你的文件结构。
3，为什么要这么做：MN独立存储笔记数据库和PDF，需要PDF位于MN内部目录来关联和识别位置
4，不论使用什么文献管理软件都有一个共同要求，就是要么设置文献目录到MN的内部资源库目录下，要么用Bindfs挂载到MN的内部资源库目录下。文献存储位置最好有个共同的总目录，而不是散乱各地的，以方便一次性挂载完。尽可能别把目录直接设置在MN的icloud目录下，这样做会产生复制成本，增加出错几率。