The challenge: a customer must be enabled to replace your delivered LGLP based library by his own one. This is for example technically not fully given for languages that do inline code from the LGPL library (e.g. templates or inline function calls in C++).
A laymen's view:
The safe way = try to avoid depending from the LGPL library.
If not possible, ask the library provider for a relaxed license model, e.g. MIT.
If not possible, get sign-off from your senior management, since a potential lawsuit is a project risk that should be managed. My advise: any use of a third party library should get sign-off for any license model of the used library: LGPL, MIT, MSPL, Apache, etc. Each license model usually contains rights and obligations (e.g. open your code, possibility to replace the library, give credits, form of delivery, etc.) which need to be checked before used in development and/or as final acceptance check that all obligations are met.
A paranoid view: There are also some technical concepts to segregate the LGPL dependent code from your closed source (e.g. a client/server architecture: your main application calls some service interface that is implemented in some server. You deliver a server implementation that bases on some (L)GPL library code. That server was open source if needed. The whole server could be replaced by anything not depending on (L)GPL in future versions. Take special care to not inject dependencies into the client/server interface: your main application provides the needed interface definition (e.g. C/C++ header file, no templates, no inline functions), not the server! I.e. the server then depends on the (L)GPL code as well as on the main application interface definitions, not vice versa).
Depends very much on you/your company to find the balance between "water proof" legal status and reasonable effort to satisfy the license obligations. There is always a certain risk for closed-source products that depend on (L)GPL to break the intent of the licenses.